Setting up a WD My Book Live NAS on Ubuntu GNOME 13.10
1st December 2013The official line from Western Digital is this: they do not support the use of their My Book Live NAS drives with Linux or UNIX. However, what that means is that they only develop tools for accessing their products for Windows and maybe OS X. It still doesn't mean that you cannot access the drive's configuration settings by pointing your web browser at http://mybooklive.local/. In fact, not having those extra tools is no drawback at all since the drive can be accessed through your file manager of choice under the Network section and the default name is MyBookLive too, so you easily can find the thing once it is connected to a router, or switch anyway.
Once you are in the server's web configuration area, you can do things like changing its name, updating its firmware, finding out what network has been assigned to it, creating and deleting file shares, password protecting file shares and other things. These are the kinds of things that come in handy if you are going to have a more permanent connection to the NAS from a PC that runs Linux. The steps that I describe have worked on Ubuntu 12.04 and 13.10 with the GNOME desktop environment.
What I was surprised to discover that you cannot just set up a symbolic link that points to a file share. Instead, it needs to be mounted and this can be done from the command line using mount or at start-up with /etc/fstab. For this to happen, you need the Common Internet File System utilities and these are added as follows if you need them (check in the Software Centre or in Synaptic):
sudo apt-get install cifs-utils
Once these are added, you can add a line like the following to /etc/fstab:
//[NAS IP address]/[file share name] /[file system mount point] cifs
credentials=[full file location]/.creds,
iocharset=utf8,
sec=ntlm,
gid=1000,
uid=1000,
file_mode=0775,
dir_mode=0775
0 0
Though I have broken it over several lines above, this is one unwrapped line in /etc/fstab with all the fields in square brackets populated for your system and with no brackets around these. Though there are other ways to specify the server, using its IP address is what has given me the most success; this is found under Settings > Network on the web console. Next up is the actual file share name on the NAS; I have used a custom term instead of the default of Public. The NAS file share needs to be mounted to an actual directory in your file system like /media/nas or whatever you like; however, you will need to create this beforehand. After that, you have to specify the file system, and it is cifs instead of more conventional alternatives like ext4 or swap. After this and before the final two space delimited zeroes in the line comes the chunk that deals with the security of the mount point.
What I have done in my case is to have a password-protected file share and the user ID and password have been placed in a file in my home area with only the owner having read and write permissions for it (600 in chmod-speak). Preceding the filename with a "." also affords extra invisibility. That file then is populated with the user ID and password like the following. Of course, the bracketed values have to be replaced with what you have in your case.
username=[NAS file share user ID]
password=[NAS file share password]
With the credentials file created, its options have to be set. First, there is the character set of the file (usually UTF-8 and I got error code 79 when I mistyped this) and the security that is to be applied to the credentials (ntlm in this case). To save having no write access to the mounted file share, the uid and gid for your user needs specification, with 1000 being the values for the first non-root user created on a Linux system. After that, it does no harm to set the file and directory permissions because they only can be set at mount time; using chmod, chown and chgrp afterwards, has no effect whatsoever. Here, I have set permissions to read, write and execute for the owner and the user group while only allowing read and execute access for everyone else (that's 775 in the world of chmod).
All of what I have described here worked for me and had to be gleaned from disparate sources like Mount Windows Shares Permanently from the Ubuntu Wiki, another blog entry regarding the permissions settings for a CIFS mount point and an Ubuntu forum posting on mounting CIFS with UTF-8 support. Because of the scattering of information, I just felt that it needed to all together in one place for others to use, and I hope that fulfils someone else's needs similarly to mine.
Installing Citrix Receiver 13.0 in Ubuntu GNOME 13.10 64-bit
28th November 2013Installing the latest version of Citrix Receiver (13.0 at the time of writing) on 64-bit Ubuntu should be as simple as downloading the required DEB package and double-clicking on the file so that Ubuntu Software Centre can work its magic. Unfortunately, the 64-bit DEB file is faulty, so that means that the Ubuntu community how-to guide for Citrix still is needed. In fact, any user of Linux Mint or another distro that uses Ubuntu as its base would do well to have a look at that Ubuntu link.
For the sake of completeness, I still am going to let you in on the process that worked for me. Once the DEB file has been downloaded, the first task is to create a temporary folder where the DEB file's contents can be extracted:
mkdir ica_temp
With that in place, it then is time to do the extraction, and it needs two commands with the second of these need to extract the control file while the first extracts everything else.
sudo dpkg-deb -x icaclient- ica_temp
sudo dpkg-deb --control icaclient- ica_temp/DEBIAN
It is the control file that has been the cause of all the bother because it refers to unavailable dependencies that it really doesn't need anyway. To open the file for editing, issue the following command:
sudo gedit ica_temp/DEBIAN/control
Then change line 7 (it should begin with Depends:) to: Depends: libc6-i386 (>= 2.7-1), lib32z1, nspluginwrapper. While there are other software packages in there that Ubuntu no longer supports, they are not needed anyway. With the edit made, and the file saved, the next step is to build a new DEB package with the corrected control file:
dpkg -b ica_temp icaclient-modified.deb
Once you have the package, the next step is to install it using the following command:
sudo dpkg -i icaclient-modified.deb
If it fails, then you have missing dependencies and the following command should sort these before a re-run of the above command again:
sudo apt-get install libmotif4:i386 nspluginwrapper lib32z1 libc6-i386
With Citrix Receiver installed, there is one more thing that is needed before you can use it freely. This is to put Thawte security certificate files into /opt/Citrix/ICAClient/keystore/cacerts. What I had not realised until recently was that many of these already are in /usr/share/ca-certificates/mozilla and linking to them with the following command makes them available to Citrix Receiver:
sudo ln -s /usr/share/ca-certificates/mozilla/* /opt/Citrix/ICAClient/keystore/cacerts/
Another approach is to download the Thawte certificates and extract the archive to /tmp/. From there they can be copied to /opt/Citrix/ICAClient/keystore/cacerts and I copied the Thawte Personal Premium certificate as follows:
sudo cp /tmp/Thawte Root Certificates/Thawte Personal Premium CA/Thawte Personal Premium CA.cer /opt/Citrix/ICAClient/keystore/cacerts/
Until I found out about what was in the Mozilla folder, I simply picked out the certificate mentioned in the Citrix error message and copied it over like the above. Of course, all of this may seem like a lot of work to those who are non-tinkerers and I have added a repaired 64-bit DEB package that incorporates all of the above and should not need any further intervention aside from installing it using GDebi, Ubuntu's Software Centre, dpkg or anything else that does what's needed.
A reappraisal of Windows 8 and 8.1 licensing
15th November 2013With the release of Windows 8 around this time last year, I thought that the full retail version that some of us got for fresh installations on PC's, real or virtual, had become a thing of the past. In fact, it did seem that every respecting technology news website and magazine was saying just that. The release that you would buy from Microsoft or from mainstream computer stores was labelled as an upgrade. That made it look as if you needed the OEM or System Builder edition for those PC's that needed a new Windows installation, and that the licence that you bought was then attached to the machine from when it got installed on there.
As is usual with Microsoft, the situation is less clear-cut than that. For instance, there was some back-pedalling to allow OEM editions of Windows to be licensed for personal use on real or virtual PC's. With Windows 7 and its predecessors, it even was possible to be able to install afresh on a PC without Windows by first installing on inactivated copy on there and then upgrading that as if it were a previous version of Windows. Of course, an actual licence was of the previous version of Windows was needed for full compliance, if not the actual installation. At times, Microsoft muddies waters to keep its support costs down.
Even with Microsoft's track record in mind, it still surprised me when I noticed that Amazon was selling what appeared to be full versions of both Windows 8.1 and Windows 8.1 Pro. Having set up a 64-bit VirtualBox virtual machine for Windows 8.1, I got to discover the same for software purchased from the Microsoft website. However, unlike the DVD versions, you do need an active Windows installation if you fancy a same day installation of the downloaded software. For those without Windows on a machine, this can be as simple as downloading either the 32-bit or the 64-bit 90-day evaluation editions of Windows 8.1 Enterprise and using that as a springboard for the next steps. Though this not only be an actual in-situ installation, there are options to create an ISO or USB image of the installation disk for later installation.
In my case, I created a 64-bit ISO image and used that to reboot the virtual machine that had Windows 8.1 Enterprise on there before continuing with the installation. By all appearances, there seemed to be little need for a pre-existing Windows instance for it to work, so it looks as if upgrades have fallen by the wayside and only full editions of Windows 8.1 are available now. The OEM version saves money so long as you are happy to stick with just one machine, and most users probably will do that. As for the portability of the full retail version, that is not something that I have tested, so I am unsure that I will go beyond what I have done already.
My main machine has seen a change of motherboard, CPU and memory, so it could have deactivated a pre-existing Windows licence. However, I run Linux as my main operating system and, apart possibly from one surmountable hiccup, this proves surprisingly resilient in the face of such major system changes. For running Windows, I turn to virtual machines and there were no messages about licence activation during the changeover either. Microsoft is anything but confiding when it comes to declaring what hardware changes inactivate a licence. Changing a virtual machine from VirtualBox to VMware or vice versa definitely does it, so I tend to avoid doing that. One item that is fundamental to either a virtual or a real PC is the motherboard, and I have seen suggestions that this is the critical component for Windows licence activation, which would make sense if that was the case.
However, this rule is not hard and fast either, since there appears to be room for manoeuvre should your PC break. It might be worth calling Microsoft after a motherboard replacement to see if they can help you, and I have noticed that it is. All in all, Microsoft often makes what appear to be simple rules only to override them when faced with what happens in the real world. Is that why they can be unclear about some matters at times? Do they still hanker after how they want things to be, even when they are impossible to keep like that?
Sorting out hogging of the Super (or Windows) Key by GNOME Shell
12th November 2013Most of the time, GNOME Shell's use of the Super (or Windows) key on a standard keyboard to open up its dash area is no issue and is a handy counterpart to what you might do in Windows, especially in its latest incarnations. However, it does cause trouble if you are using a VirtualBox virtual machine with Windows installed in there. While VMware Player is immune to this problem, I thought that I would see if there was a workaround for it.
Though the issue might arise from VirtualBox's non-grabbing of the Super key like others, a solution can be found in GNOME itself. Opening up dconf-editor and navigating to org > gnome > mutter. In there, you will find a setting called overlay-key and this can be changed. One option is to delete the SUPER_L value and leave it that way. My own preference was to set it to a different key and, to accomplish that, I needed to know what the various key identifiers were. To get these, I ran the following command (just replace any quotes with alternatives in the shell before executing this):
xev | grep -A2 --line-buffered '^KeyRelease' | sed -n '/keycode /s/^.*keycode \([0-9]*\).* (.*, \(.*\)).*$/\1 \2/p'
This opened up an Event Tester window that will need to be closed when testing is complete. More importantly, the aliases for any keys that were pressed are issued to the terminal session so you can see what's what. Initially, the one for the Alt Gr key appealed to me, and I set "ISO_Level3_Shift" as the value of the overlay-key property in dconf-editor. When that didn't work, I set the value to "Menu" and it behaved as expected. While this will mean that context menus will have to be accessed by right-clicking in a Windows session, that is what I do anyway, so there will not be much of a loss in what I have done. Though a function key might have been another option, I reckon that the context menu key will do me.
A way to get Rigo working again in Sabayon
23rd October 2013After having Sabayon running on a PC until it came to pieces after an attempted version upgrade, I went away from the Linux distro for a while and Linux Mint now runs on the aforementioned machine. It only was a certain curiosity that got me installing it into a virtual machine on VirtualBox to see if my command line method of keeping the system up to date was the cause or whether rolling or partially rolling distros have a certain fragility that is not seen in their discrete release counterparts.
Recently, that ran into a hitch, the Sabayon package manager Rigo failed to start up for me. After waiting to see if it sorted itself on its own, I looked into returning to those command line ways, and that line of enquiry led me to a method of restoring Rigo's functionality from Sabayon's wiki page on the underlying Entropy. The first step was to issue a command to become root:
su
That needed the appropriate password, and the next command issued updated Sabayon's repositories:
equo update
Once that had done its thing, it was time to install new versions of Entropy and Rigo:
equo install entropy rigo
With that complete, it was time to exit the root session with the exit command. Then, it was time to try running Rigo and it worked as expected. Any thoughts of adding in the superseded Sulfur (Rigo's predecessor) were banished on seeing that success.
Surveying changes coming in GNOME 3.10
20th October 2013GNOME 3.10 was released last month, but I only saw it when it appeared in the Arch and Antergos repositories. Despite stability risks, this showcases a strength of rolling distributions: they let you see the latest software before others. Otherwise, you might need to wait for the next Fedora release to view GNOME updates. This delay isn't always negative, as Ubuntu GNOME typically uses the previous version. Since many GNOME Shell extension developers don't update until Fedora includes the latest GNOME in a stable release, this approach ensures the desktop environment is well established before reaching Ubuntu. Debian takes this further by using a stable version from years ago, which has merits for system reliability.
As I regularly use GNOME Shell extensions, I'm interested in which ones still work, which need tweaking, and which no longer function. The main change in the top panel is the replacement of separate sound and user menus with a single combined menu. Extensions that modified the user menu now need reworking or abandoning. The GNOME project has adopted an irritating habit similar to WordPress, with frequent API changes that break extensions (or plugins in WordPress). However, GNOME should copy WordPress's approach to documentation, particularly for the API, which is barely documented anywhere.
GNOME Shell theme developers face challenges too. When I used Elementary Luna 3.4, a large border appeared around the panel, so I switched to XGnome Enhanced (found via GNOME-Look.org). The former theme is no longer maintained as its developer has stopped using GNOME Shell. Perhaps someone else could take it over, since it worked well until version 3.8. The new theme works well for me and will be an option if I upgrade to GNOME 3.10 on one of my PCs in the future.
Returning to the subject of extensions, I tested the included Applications Menu extension, which has improved stability and looks very usable. I no longer need to wait for the Frippery equivalent to be updated. The GNOME Shell backstage view hasn't changed much since 3.8, which may disappoint some, but the workaround works well. Several extensions I use frequently haven't been updated for GNOME Shell 3.10 yet. After some success before a possible upgrade to Ubuntu GNOME 13.10 and GNOME Shell 3.8 (though I'm staying with version 13.04 for now), I tried to port some of these to the latest interface. Below are my updated extensions, which you can use until they're officially updated on the GNOME Shell Extensions website:
GNOME 3.10 brings other modifications beyond GNOME Shell, which is mainly a JavaScript construction. Application title bars continue to be consolidated in GNOME applications, with a prominent exit button now appearing. You can still apply the previously mentioned modifications to Nautilus (also called Files), many of which work with other applications like Gedit. Gedit now includes useful 'x of y' numbering for search results, showing the current match number and total matches. The GNOME Tweak Tool has been overhauled, but no longer includes the setting for showing folder paths in Nautilus. To enable this feature, open dconf-editor, navigate to org > gnome > nautilus > preferences and tick the always-use-location-entry box.
The GNOME project continues on its path established a few years ago. While I wish GNOME Shell were more mature, significant changes are still coming, making me wonder when this will stop. This might be the result of introducing a controversial experiment when users were content with GNOME 2. Fedora 20 should bring more updated GNOME shell extensions. Antergos provides a good way to see the latest GNOME version if it remains stable. Cinnamon fans may be happy that Cinnamon 2.0 is another desktop option for the Arch-based distribution, one that I may discuss this further once the Antergos installer stops failing at package downloads. I'm setting up a separate VM to examine Cinnamon because it destabilised GNOME during a previous review.
A look at Ubuntu GNOME 13.10
12th October 2013With Ubuntu GNOME 13.10's final release approaching, I decided to try the beta version to see what's coming. However, I accidentally downloaded and installed the 64-bit edition of 13.04 in a VirtualBox virtual machine. My plan to update this to the upcoming release failed due to instability, so I couldn't test an in-place upgrade to 13.10. Originally, I had intended to use this command:
gksu update-manager -d
However, I found another one when considering how Ubuntu Server might be upgraded without the GUI application that is the Update Manager. To update to a development version, the following command is what you need:
sudo do-release-upgrade -d
To upgrade to a final release of a new version of Ubuntu, drop the -d switch from the above to use the following:
sudo do-release-upgrade
There is one further option that isn't recommended for moving between Ubuntu versions, but I use it to get updates, such as new kernel subversions that are released:
sudo apt-get dist-upgrade
Rather than trying out the above, I downloaded the latest ISO image for the beta release of Ubuntu GNOME 13.10 and installed onto a VM that instead. Though it is the 32 bit version of the distro that is installed on my main home PC, it has been the 64 bit version that I have been trying. So far, that seems to be behaving itself even if it feels a little sluggish, but that could be down to the four-year-old PC that hosts the virtual machine. For a while, I have been playing with the possibility of an upgrade involving an Intel Core i5 4670K CPU and 16 GB of RAM (useful for running multiple virtual machines at a time) along with any motherboard that supports those, so looking at a 64-bit operating system has its uses.
The Linux kernel is 3.11, but that's not my main concern. Neither am I worried about LibreOffice 4.1.2.3 being included while GIMP (version 2.8.6) wasn't, since it can be added easily. What drew me to explore the upcoming release was the move to GNOME Shell 3.8, as I rely on many extensions. Like WordPress and its plugins, GNOME Shell has a difficult relationship with extensions, and I wanted to see which still worked. The backstage application view has changed. Now you either see all installed applications or must type the name of the one you want. Losing the categorical view from GNOME Shell 3.6 is a backward step, and I hope version 3.10 brings it back. Although you can add categories, the result is inferior to the original. Users shouldn't need to modify system internals for such basic functionality. With all these constant changes, it's unsurprising that Cinnamon has become independent with version 2.0, and that Debian considered not using GNOME for its latest version (7.1 at the time of writing, which wisely chose GNOME Shell 3.4).
Having had a look at other distribution that already have GNOME Shell 3.8, I knew that a few of my extensions worked with it. The list includes Frippery Bottom Panel, Frippery Move Clock, Places Status Indicator, Removable Drive Menu, Remove Rounded Corners (not really needed with the GNOME Shell theme that I use, Elementary Luna 3.4, but I retain it anyway), Show Desktop Button, User Themes and Ignore_Request_Hide_Titlebar. Because of the changes to the backstage view, I added the Frippery Applications Menu instead of the Applications Menu because I have found that to be unstable. Useful new discoveries have included Curtains Up and GNOME Shell Open Terminal, while Shell Restart User Menu Entry has made a return and found a use this time around too.
There have been some extensions that were not updated to work with GNOME Shell 3.8 that I have got working. In some cases, it was as simple as updating the metadata.json file for an extension with new version numbers of 3.8 and 3.84 to the list associated with the shell version property. All extensions are to be found in the .local/share/gnome-shell/extensions location in your home directory, and each has a dedicated file containing the aforementioned file.
With others, it was a matter of looking in the Looking Glass (execute lg in the box that ALT + F2 brings up on your screen to access this) and seeing what error messages were to be found in there before attempting to correct these in either the extensions' extension.js files or whatever JavaScript (*.js) file was causing the problem. With either or both of these remedies, I managed to port the four extensions below to GNOME Shell 3.8. In fact, you can download these zip files and install them yourself to see how you get on with them.
Advanced Settings in User Menu
There is a Remove Panel App Menu that works with GNOME Shell 3.8, but I found that it got rid of the Places menu instead of the panel's App Menu, so I tried porting the older extension to see if it behaved itself and it does. With these in place, I have bent Ubuntu GNOME 13.10 to my will ahead of its final release next week, which includes customising Nautilus too. Other than a new version of GNOME Shell, it looks as if it will come with less in the way of drama and a breather like that is no bad thing given that personal computing incessantly remains in a state of flux these days.
Turning off seccomp sandbox in vsftpd
21st September 2013Within the last week, I set up a virtual web server using Arch Linux to satisfy my own curiosity, since the DIY nature of Arch means that you can build up exactly what you need without having any real constraints put upon you. Something that didn't surprise me about this was that it took me more work than the virtual server that I created using Ubuntu Server, yet I didn't expect Proftpd to be missing from the main repositories. Though the package can be found in the AUR, I didn't fancy the prospect of dragging more work on myself, so I went with vsftpd (Very Secure FTP Daemon) instead. In contrast to Proftpd, this is available in the standard repositories and there is a guide to its use in the Arch user documentation.
However, while vsftpd worked well just after installation, connections to the virtual FTP soon failed with FileZilla began issuing uninformative messages. In fact, it was the standard command line FTP client on my Ubuntu machine that was more revealing. It issued the following message that let me to the cause after my engaging the services of Google:
500 OOPS: priv_sock_get_cmd
With version 3.0 of vsftpd, a new feature was introduced, and it appears that this has caused problems for a few people. That feature is seccomp_sandbox and it can be turned off by adding the following line in /etc/vsftpd.conf:
seccomp_sandbox=NO
That solved my problem, and version 3.0.2 of vsftpd should address the issue with seccomp sandboxing anyway. In case, this solution isn't as robust as it should be because seccomp is not supported in the Linux kernel that you are using, turning off the new feature still needs to be an option, though.
Customising Nautilus (or Files) in Ubuntu GNOME 13.04
12th September 2013The changes made to Nautilus, otherwise known as Files, in GNOME Shell 3.6 were contentious and the response of the Linux Mint was to create their own variant called Nemo from the previous version of the application. On the Cinnamon or MATE desktop environments, the then latest version of GNOME's file manager would have looked like a fish out of water without its application menu in the top panel on the GNOME Shell desktop. It is possible to make a few modifications that help Nautilus to look more at home on those Linux Mint desktops, and I have collected them here because they are useful for GNOME Shell users too. Here they are in turn.
Adding Application Menu entries to Location Options Menu
The Location Options menu is what you get on clicking the button with the cog icon on the right-hand side of the application's location bar. Using Gsettings, it is possible to make that menu include the sort of entries that are in the application menu in the GNOME Shell panel at the top of the screen. These include an entry for closing the whole application, as well as setting its preferences (or options). Running the following command does just that (if it does not work as it should, try changing the single and double quotes to those understood by a command shell):
gsettings set org.gnome.settings-daemon.plugins.xsettings overrides '@a{sv} {"Gtk/ShellShowsAppMenu": <int32 0>}'
Adding in the Remove App Menu GNOME Shell extension will clean up the GNOME Shell a little by removing the application menu altogether. If, for some reason, you wish to restore the default behaviour, then the following command does the required reset:
gsettings set org.gnome.settings-daemon.plugins.xsettings overrides '@a{sv} {}'
Stopping Hiding of the Application Title Bar When Maximised
By default, GNOME Shell can hide the application title bars of GNOME applications such as Nautilus on window maximisation and this is Nautilus now works by default. Changing the behaviour so that the title bar is kept on maximised windows can be as simple as adding in the ignore_request_hide_titlebar extension. The trouble with GNOME Shell extensions is that they can stop working when a new version of GNOME Shell is used, so there's another option: editing metacity-theme-3.xml but /usr/share/themes/Adwaita/metacity-1. The file can be opened using superuser privileges using the following command:
gksudo gedit /usr/share/themes/Adwaita/metacity-1/metacity-theme-3.xml
With the file open, it is a matter of replacing instances of ' has_title="false" ' with ' has_title="true" ', saving it and reloading GNOME Shell. This may persevere across different versions of GNOME Shell, should the extension not do so.
Disabling Recursive Search
This discovery is what led me to bundle these customisations in an entry on here in the first place. In Nemo and older versions of Nautilus, just typing with the application open would lead you down a list towards the file that you wanted. This behaviour was replaced by an automatic recursive search from GNOME Shell 3.6 where the search functionality was extended beyond the folder that was open in the file manager to its subdirectories. To change that to subsetting within the open folder or directory, you need to install a patch version of Nautilus using the following commands:
sudo add-apt-repository ppa:dr3mro/personal
sudo apt-get update && sudo apt-get upgrade
The first of these adds a new repository with the patched version of Nautilus, while the second combination installs the patched version. With that done, it is time to issue the following command:
gsettings set org.gnome.nautilus.preferences enable-recursive-search false
That sets the value of the new enable-recursive-search option to false for searching within an open directory. It also can be found using Dconf-Editor in the following hierarchy: org -> gnome -> nautilus -> preferences. The obsession of the GNOME project team with minimalism is robbing users of some options, and this would be a good one to have by default too. Maybe the others should be treated in the same way, even if you need to use Gsettings or Dconf-Editor to change them to avoid clutter. Having GNOME Tweak Tool able to set them all would be even better.
A Look at a Compact System Camera
4th September 2013In August, I acquired an Olympus Pen E-PL5, and I'm still getting used to it. Its main appeal was combining SLR functionality with compact camera size. This was an upgrade from my Canon PowerShot G11 without the bulk of a larger camera.
When I considered Canon's EOS M before choosing the E-PL5, I was put off by its slow autofocus. The lack of a mode dial was another concern, though its APS-C sensor and price of around £399 were attractive (and I liked Canon's tendency to overexpose when examining images from an old Canon EOS 10D). After seeing a camera comparison in Practical Photography, I bought that issue. They preferred the similarly priced Olympus Pen E-PM2 over the Canon. Though a Panasonic won the test, I was interested enough in the Olympus to research further. Unlike the E-PM2 and EOS M, the E-PL5 has both a mode dial and extra grip, so I chose it despite the higher price. I had noticed discounted Olympus Pen models before, but this purchase was a more deliberate investment.
Breaking my usual preference for black cameras for variety's sake, I chose the silver E-PL5 from the three available colours (black, silver and white). The body is very compact, with the lens taking up most of the bulk. The standard 14-42 mm zoom means this isn't a shirt-pocket camera, so I bought a black Lowepro Apex 100 AW case. The case fits the camera snugly, making me wonder if I should have chosen a larger one, but it's working well. To protect the lens during outings, I also added a 37 mm Hoya HMC UV filter. The lens's plastic construction extends further than I expected and doesn't fully retract into its housing like some of my Sigma lenses.
On my first test run, I needed to work out how to hold the camera. My Canon PowerShot G11's powered zoom and autofocus made it more intuitive to hold, as was true for any SLR I've used. Holding the small body while adjusting the zoom lens was awkward at first. Eventually, I learned to steady the body with my right thumb (the curved thumb grip on the back holds a thumb vertically) while freely adjusting the lens with my left hand. An electronic viewfinder instead of the screen would have made things easier, but they're expensive, and I had already spent enough.
After learning to hold the camera, I needed to adjust to its exposure characteristics. From my experience, it tends to overexpose. Though I set it to store raw (ORF) files that can be fixed later, I prefer more control during capture. Also, I haven't found a spot or partial metering button like those on my SLR or G11. This means either using exposure compensation with aperture priority mode or switching to fully manual exposure. Other familiar modes are available (shutter priority, program, automatic, etc.). While getting familiar with the camera, I'm using bracketing after setting ISO to 400, increasing screen brightness and adding histograms to playback views. As my grip becomes more secure, I'm using the dial to adjust settings like aperture (f/16 remains my favourite despite what others think about micro four thirds sensor size) and compensation, keeping scenes consistent to test the camera's response to changes.
Though I'm still learning, I'm seeing pleasing results that encourage me to continue; some remind me of my Pentax K10D. The E-PL5 is slower to use than the G11, but that's often beneficial for photography. Being forced to slow down in our hectic world is another advantage. The G11 is seeing less use now, with sunny days offering chances for more experimentation and familiarisation. My introduction to compact system cameras has shown they're very different from compact fixed lens cameras or SLRs. Neither type is truly replaced; instead, a new category has emerged.