Recap on SeaMonkey 1.1 > 2.0 migration: Add-on caveats

Themes

Even if a profile is migrated, SeaMonkey 2.0 will default to its default theme. If you used a Modern theme (built-in), then you'll have to choose it from the Add-on Manager and restart SeaMonkey. The selection and amount of themes for SeaMonkey 2.0 is different than for SeaMonkey 1.x.

Extensions (this is the difficult part)

• Extensions must be installed anew.


• The whitelist of servers where extensions and themes can be installed from might not be migrated.


• Globally installing an extension requires administrative rights.
  
  Unlike with Mozilla Firefox, whereby globally installing an extension installs it into every private user profile for all users of an operating system (so that there are multiple copies around of the same extension), doing this for SeaMonkey actually installs the extension into SeaMonkey's extensions folder that resides in the program's install directory.
  
  The pitfall is that a limited Windows xp user would then be unable to update a required extension for compatibility. I had that with two spelling dictionaries.
  
  The quick-and-dirty solution in my case was to temporarily set the user as administrator, update the extension for compatibility and then remove the user's administrator credentials. Bah.
  
  While global extension installation could potentially be very convenient in terms of getting to install only one extension at once for all profiles (=different SeaMonkey users), it does introduce a number of security and other considerations:
  
  
  
  1. One is that, for example, in Windows xp, SeaMonkey is installed into the Program Files folder, where limited users have limited rights, which means that they cannot update the extension, even for compatibility (can't modify folder contents).
  
  
  2. If SeaMonkey were installed into a public directory — such as
     C:\Documents and Settings\All Users\Documents — then the whole suite would be left vulnerable to tampering either by its users or a malicious program (both would have to have awareness of the program's different location).
  
  
  3. Change user access rights for relevant extensions' folders where they are in
     Program Files\SeaMonkey\extensions.
     
     A few words of caution: I have not tried this myself, but some of the user support forum topics related to SeaMonkey have suggested that limited users should be given rights to the whole SeaMonkey install directory, so that they would be able to update their extensions. I do not recommend giving rights to the whole program directory, but giving rights to limited users for only the extensions directories.
     
     While this would make SeaMonkey reasonably tamper-proof, the extensions would be the few to remain vulnerable to tampering.
     
     To easily see which add-on is installed into which folder, install the MR Tech Toolkit extension. It extends the Add-on Manager with lots of useful tools, but the function you need is "Browse install directory" when right-clicking an extension.
     
     Once the Windows Explorer folder for the extension is open, click on the folder whitespace, and on the Properties command. This should open the Properties window for the current folder. There, in the Security tab, click on Users from the Group or User names list and click on the Modify checkbox in the "Allow" column. Click the Apply button, but don't leave the window yet. Click the Advanced button and in the "Advanced Security Settings for extensionfoldername" list, verify that the set permissions for separate user(s) or a group of users apply to "This folder, subfolders and files".
     
     This action thus leaves SeaMonkey more-or-less tamper-proof, but may leave directories of specific extensions vulnerable to tampering.
  
  
  4. Best to install extensions separately into every profile? What if there are more than five users and what if a few of those users have more than one SeaMonkey profile?


• I had trouble installing Flashblock from addons.mozilla.org, so I had to add flashblock.mozdev.org to the whitelist and install from there. No trouble installing NoScript from addons.mozilla.org.


• As it usually is with SeaMonkey browsers, the Flashblock toolbar button will not show automatically. Instead of opening the Preferences window, click on any free space in the SeaMonkey toolbar, then on Customize... A Firefox-like toolbar customization dialog should show up and the Flashblock toolbar item can be added wherever a user chooses in the toolbar (the standard location was next to the Home button in the Personal Toolbar). Because the computer where I installed SeaMonkey 2.0 does not have a printer, I dragged the printer button off the toolbar.


• Server whitelists for Flashblock and NoScript do not migrate automatically. I had to manually type in server names into the new Flashblock whitelist, but I think its file can be migrated (haven't checked how to do it). NoScript allows exporting the whitelist, so I did that from SeaMonkey 1.1 and imported the whitelist in SeaMonkey 2.0 after installing NoScript.

It has always been the developers' intention for Mozilla (later SeaMonkey, which became Mozilla's successor; and a branched-off Mozilla Firefox) to have global and per-user extensions.

Mozilla 1.0 finally came out on 05.06.2002. Seeing what Mozilla 1.0's (minimum) system requirements were (modest by nowadays' standards) can give a helpful glimpse into what kind of hardware and software people were using at that time.

This was an era when single-user operating systems in computers were still a norm: four years after the release of Windows 98 and two years after Windows Me was released. Hard disk capacity then (2001–2002) — well, roughly ten years back — was about 10% of what it is now (2010) and there wasn't any lack of people who used much older computers. It's duly possible that hard disk capacity was seen as a premium back then, because after Mozilla 1.0 was released, it was criticized for its bloat.

Mozilla 1.0's full installer for Windows was 9.8 Mb, releases for Linux were between 11.6–13.9 Mb, and release sizes for exotic operating systems ranged between 16–26 Mb. The size of the Windows installer was actually normal, because the installers for Netscape Communicator 4.x and Internet Explorer 5 weren't all that much more smaller, as both included bundled software.

I guess the bloat factor was two-pronged:

Those who lived through those times, can remember how Internet Explorer reigned supreme.

Actual software bloat

IE users eager to try out something new would probably perform a 'normal' install of Mozilla (or Netscape 6.X) and only thereafter discover that Mozilla wasn't only a browser, but an application suite with an extensive feature set, while Internet Explorer was duly perceived as a stand-alone program. And that the typical installs of Netscape 6.X would also bundle a number of other tag-along apps, like RealPlayer and AOL Instant Messenger.

In all actual fact, Outlook Express, Windows Media Player, Microsoft NetMeeting and various other bits were just as well bundled with large ('Normal'/'Typical') Internet Explorer installations, only that Internet Explorer was marketed by Microsoft as an inalienable part of the Windows operating system; other said programs were bundled as parts of Windows 95OSR2.x, Windows 98/Me and newer. Yet people launching Internet Explorer both on Windows and Mac knew and saw that they were only launching a browser and not a whole suite of applications (e-mail, newsgroups, chat/IM) they probably didn't have any need for.

Slow user interface responsiveness

Much of Mozilla's user-facing behaviour was based on Netscape Communicator 4.x, but its cross-platform user interface toolkit was completely new.

Netscape 6.X and newer were subsequently based on Mozilla's underlying code base. People used to Internet Explorer or even Netscape 4.x found Mozilla 1.0 as not particularly responsive compared to IE and Netscape 4.x and I know I can attest to that when seeing SeaMonkey 1.1.xx work on older hardware.

In terms of system resource usage, Mozilla 1.0 would run more-or-less properly on the kind of metal specified in its system requirements. Nevertheless, the new cross-platform user interface toolkit (intended to ease development, which I believe it did) was not native to any existing operating system and thus imposed a performance penalty on any hardware that wasn't top-of-the line. Hence the talk of bloat.

All this gave plenty of impetus for Mozilla developers to create a separate browser which eventually came to be Mozilla Firefox. And lo and behold, Mozilla Firefox 1.0 ran well and faster on even older hardware (CPU considerations aside).

To continue soon?

---

What is so great about SeaMonkey, is that the underlying technology didn't change much throughout the great ten years between Mozilla 1.0 and SeaMonkey 1.1.19, which really is proof of the package's superiour design considerations.

Netiquette: Large images and the Internet

In July 2008, a family member far away wrote me that she had been having trouble sending images to people. So here's an article that I initially wrote for her, but decided to re-edit and publish it in here for all to read. She sent me four very large photos.

Netiquette

The photos in their original photographed size are very large, which is why most Internet service providers intentionally impose technical limitations in their e-mail servers on the size of e-mail that can be transferred. The original large size of the photos is useful for when there's a need make high-quality prints (even above the 3x4" or 10x15 cm range).

When view digital photos in a new computer, then it is powerful enough to be able to temporarily resize them to the proper viewing size every time they are opened for viewing. This functionality may create an illusion that the images are not as large as they really are.

An important part of the netiquette in e-mail is to send messages that have reasonable sizes, so as not to constrain all the server computers and network traffic routers through which e-mail passes through. All servers have restrictions as to how large an outgoing message can be. A user's outgoing server may have lax restrictions, the addressee server may not.

Photos that people send to others are usually very likely to appear in a message in-line, when that message is being viewed in an e-mail folder. Some e-mail programs allow automatic resizing of images, so they equally create an appearance of a size that fits.

One solution is to send large photos on a piecemeal basis, especially if there is an actual requirement to send large images.

One way to know how much a sender can send at a time is to see the error message of a returned letter. Somewhere down there must be an error message stating the permitted space limit. Note that addressees' servers' limits on the size of incoming messages always differ. Pass-through mail servers may also have their internal space limits.

Another solution to sending images is to compress them into one .zip file, for example. In Windows XP and Vista, there is a built-in compression program with functionality to select a bunch of photos, then click on the selection with the right mouse button and select "Send To" > "Compressed (zipped) Folder".

Oftentimes (and even then) the collections of photos even in a compressed file may end up too large. Compression of files also takes time, so if there are lots of large files, compressing and uncompressing them takes some time.

Resizing/scaling images

Yet another solution is to resize all images to something the expected size of people's screen resolutions. For example, the four photos I received this February were each more than two megabytes in size and that is really huge. Even individual images are large. One way to reduce their size is to scale them down with a good image processing program.

For example, a particular group pose photo I received is 3264x2448 pixels in size (width x height). This would probably fit a large wide-screen monitor or be proper for an equally capable projector. Most people's computer screens are nowadays set to 1024x768 pixels.

When opting to send a fair number of not-so-small photos through online means, then, yes, it is a really good practice to resize them.

My favourite tool for this is The GIMP &nmdash; The GNU Image Manipulation Program (GNU is a recursive acronym for GNU's not UNIX). The latest release is 2.6.2 and it contains many improvements over the 2.4.x [development] branch, the major version that I had been thinking of mentioning when writing this instruction set long before the 2.6 version suddenly came out.

The GIMP is available from gimp.org

If there are many images...
For batch processing, there is a plugin for GIMP called DBP — or David's Batch Processor. DBP is available from here. (Download link on the left side of the page.)

Extract the executable (an application) into this directory (it's better if GIMP is not running at that time):
C:\Program Files\GIMP-2.0\lib\gimp\2.0\plug-ins
Run GIMP after that and the extension is under the Filters menu as a "Batch process..." command. Note that the extension also launches a command-line window. It can be minimized.

The user interface of the Batch process plugin is more or less straight-forward.

• When adding images, choose those that are similar in their features — for example that the width of every image should be longer and height shorter: the batch processor will otherwise make a portrait-positioned image out of landscape-shaped images ugly. The resultant image can later be turned to the suitable portrait/landscape position.


• Under Resize tab, enable the Resize function.
  If the image size is 3264x2448, then it is important to first test through an individual scale process to see what the results are. Choose Scale from the Image menu.
  For example, scale the image to resize it to a 1024 pixel width (the height is calculated automatically). The result should be 1024x768, if the aspect ratio is 4:3 (or 3:4), if memory serves me right.
  The reason for this is that while the DBP plugin's resize function allows relative resizing whilst keeping the aspect ratio, it's impossible to tell what the resultant width in pixels would be.
  That is why I choose absolute resizing, knowing that the aspect ratio will be maintained, if I set the absolute width and height to 1024x768 pixels — if a 3264x2448-pixel image scales to 768-pixel height if the width is previously set to 1024 pixels.


• The Rename tab's functions allow choosing a different destination directory and in the Output tab a relevant image format must be specified — JPG for photos and PNG for non-photographic material (pictures, screenshots, drawings, etc.). After setting JPG as the output format, the image quality must be set to 100 (the output will still be considerably smaller, even with a 100% image quality). Other things can be left as default.

Optical Disc authoring

One way of physically sending a large batch of photos is to buy a quality optical disc (typically one with gold as the default/main metal of use; Some products are geared/optimized toward a certain task, such as audio burning, data, photos, etc.), such as a CD-R (Recordable) or CD-RW (Rewritable) from a known brand with a history of producing writeable media (EMTEC, Verbatim, TDK, Philips, Sony, Maxell) — and burn the photos there.

For more size, a recordable DVD presents a good option. There are several recordable DVD formats, but it's best to choose the format that the optical disc writer at hand supports. Both CD's and DVD's come in various sizes, so if there's only up to 200 megabytes of photos to burn, an equally fitting pocket-sized CD is the ideal option — only that it may cost less than a vanilla 650–700 Mb CD-R. Standard-issue CD-R-s can store from 650 to 700 megabytes, depending on specification.

Rewritable optical discs (marked with XXX-RW or XXX+RW) are useful for testing. When I last burned data, I discovered a rewritable CD was very useful, because of a program setting I forgot to set in K3b, an optical disc authoring program in Linux, and so several burning sessions were lost and this allowed me to make mistakes. Rewritable optical discs have lesser storage latency, though, compared to one to which data is written to permanently.

On the other hand, rewritable discs are great for short-term projects, such as when using a backup application for the first time or trying out another program for disc authoring.

In addition to selecting a quality disc, the packaging also shows the suggested recording speed or a range of speeds. I've seen TDK's CD-s' packaging with the specification of "Up to 52x" writing speed. The great thing about it is that such language is not ambiguous.

Some writeable CD's have specified 4–16x writing speed. While 52x writing speed may be fast and may save time, it may not be useful for long-time storage of data, as error correction information is not saved because of such a speed of writing, so choosing the slowest possible speed is best for long-term storage, provided that the disc is equally suited for it.

Optical discs are also sensitive to elements, so that combining all the best practices reduces the chances of data loss. Some good disc manufacturers already produce optical media that have protection against elements, such as ultra-violet light and scratching. They are more expensive and usually geared toward heavy-duty use, but are all the more durable.

Once a burn is complete, it's important to use a marker specially labelled to be used on optical discs (CDs and the like).

More in a Wikipedia article about CD-R's, with plenty of essential advice on authoring an optical disc. The right-hand sidebar also shows links to other formats, just that CD-R is one of the cheapest ways to store data longer-term off a hard drive /my own long-term experience has shown that hard drives may eventually fail.