Installing Fedora 16 (Verne) dual-boot with Windows 7

Back in February I finally got around to installing Fedora 16 (Verne) as a dual-boot option on my Windows 7 home machine. I was helped considerably by an impressively detailed tutorial on How to dual-boot Fedora 15 and Windows 7 posted on the LinuxBSDos.com blog, which was invaluable for the tricky steps of partitioning and boot loader set up.

In this post I give an overview of what I did for my own dual-boot installation, with some hints and tips that I picked up in the process.

Preparation: back up the existing system

My first step was to make an image of the existing system on an external hard drive so that I could recover everything if the installation should fail for any reason. To do this I used Clonezilla Live, which can be burned onto a CD or other bootable media (I used the 1.2.12-10 AMD64 iso). I found the Clonezilla website quite difficult to navigate but there are very detailed usage instructions at http://www.clonezilla.org/clonezilla-live-doc.php, and while Clonezilla Live's menu-driven structure might feel a bit retro to those used to a slicker UI, the program itself turns out to be very easy to use.

Note that the size of the resulting image file (and hence the amount of space required on the external drive) depends on how much of the disk actually contains data, rather than the size of the disk or partition being imaged. So although the Windows partitions had been allocated the whole of my 1 TB hard drive, in this case only about 70 GB was in use and the corresponding image file was even smaller at around 45 GB.

Repartitioning: create space for the Fedora installation

Having created the image the next step was to free up some space by shrinking the size allocated to the Windows partitions (the LinuxBSDos dual-booting tutorial assumes there's already some free space available for the Fedora install). To do this I used GParted Live (version 0.11.0-10), a free partition editor that runs from bootable media and works with 64-bit systems. Launching the GParted application from the bootable CD is covered at http://gparted.sourceforge.net/display-doc.php?name=gparted-live-manual and there is comprehensive documentation on how to use it (with screenshots) at gparted.sourceforge.net/display-doc.php?name=help-manual. However I think the user interface is pretty intuitive on its own. For my installation I reduced the Windows allocation down to 50% of the disk space, leaving around 500 GB of unallocated space.

Installing Fedora 16

I was now in a position to install Fedora into the free space. I downloaded and burned the Fedora 16 installable live media (aka Live Desktop CD) from http://fedoraproject.org/en/get-fedora (make sure you get the appropriate 32- or 64-bit version for your system), which also allows you to try out Fedora without installing (see my previous post on Fedora 15 and Gnome 3 user basics if you're unfamiliar with the Gnome 3 desktop).

Detailed information about the installation procedure can be found in the extensive Fedora 16 Installation Guide but in summary this is what I did:

• Booted the system from the Fedora Live Desktop CD and started the installer via Activies/Applications/Install to Hard Drive.

• Clicked through the installer screens and set up keyboard layout, computer name, network setup, computer name, and timezone etc (generally if you're installing a vanilla home desktop system then the default options should be okay) until I reached the Type of installation screen. Here I needed to tell the installer where to put Fedora:
  
  • Choose the Use Free Space option to use the unallocated disk space, and
  • Make sure the Review and modify partitioning layout option is checked.
  before clicking through to the next screen.

• The next step was to modify the assigned logical volumes to my preferred layout (here the detailed instructions in the LinuxBSDos blog post were invaluable; I strongly recommend consulting them if you're unfamiliar with logical volumes and partitions). For my installation I changed the Fedora defaults to set up the following new partitions:
  
  • lv_root (/): 10 GB
  • lv_home:
  • /home: 75 GB
  • /boot: 500 MB
  • lv_swap: 16 GB
  Generally it's recommended to only use the space you need for the new installation and leave unused capacity unallocated; keeping /home separate from the root partition means that I can share user directories between multiple Linux installations in future; and the recommendation is that swap should be allocated around twice the size of the system RAM. However more elaborate partitioning schemes can be created, with various pros and cons - there's useful information on this in the Recommended Partitioning Scheme section of the Fedora documentation.

• Having set up the partition layout, I then needed to change the location of the Fedora boot loader (GRUB) from the default of Master Boot Record to First sector of boot partition. The reason for this is that any changes that are made to the Master Boot Record (MBR) (such as installing GRUB) are liable to be overwritten by future Windows updates, so it's better to manage the boot options from within Windows after Fedora has been installed:
  
  • Click Change Device and select First sector of boot partition (I'd recommend verifying that the correct location is shown before clicking Next to complete the installation, and also making a note of the boot loader location for reference later).

At this point I was finished and the installation could complete, which was a relatively quick process (in my case it took around 5 minutes).

Configuring the Windows boot manager

Once the installation process had completed the computer rebooted directly into Windows, so to be able to access Fedora I needed to update the Windows boot manager: for this I used EasyBCD 2.1.2 (EasyBCD is a Windows bootloader editor freely available from NeoSmart Technologies) as recommended in the LinuxBSDos.com tutorial. Once installed in Windows I was able to add a new entry for Fedora 16:

• Click on the Add New Entry tab
• Select the Linux/BSD tab and select the partition that the GRUB boot loader was installed to (which I made a note of earlier)
• Select Edit Boot Menu to view the change

Then restarting the system then gave me the option of booting either Windows or Fedora 16.

(Note that using this method, when Fedora 16 is selected you get the Linux GRUB boot loader rather than just booting directly into Linux; however it should be possible to configure GRUB to boot Fedora immediately.)

Post-installation Fedora set-up

Once Fedora 16 was booted for the first time, there were a few standard post-installation steps to complete: agreeing to the user license, setting up the date and time - usually I select the option to synchronise over the network - and creating a non-root user account. I also ran the Software Update application to pull in any updates (this also fixed the settings for my monitor, which initially weren't properly configured). It was then possible to start building up the software inventory and configuring the system to my personal preferences.

The final thing I did was to make donations to the Clonezilla, GParted and EasyBCD projects, as I would have been unable to set up my dual-boot system without them. It's also worth taking a moment to acknowledge the efforts of the Fedora community and the wider Linux community for making a complete operating system available and easy to install at no cost to the end user.

For my part I hope that this overview will be useful to someone else - and good luck with your own dual-booting installations.

Firefox add-ons for the occasional web developer

I'm not a hardcore web developer but I do some occasional web-based work, and one of the issues I have is that - because web applications exist in an environment which spans both browser and server (and which often seems to hide the workings of its components) - it can be quite difficult to see under the hood when there are problems.

Fortunately there are a number of adds-on for Firefox (my browser of choice) that can help. These are the ones that I like to use:

• Firebug http://getfirebug.com/ is possibly one of the most essential add-ons for web development. I first came across it as a Javascript logger and debugger, but it's far more than that: describing itself as a complete web development tool, its functionality extends to HTML and CSS in additional to script profiling and network analysis capabilities. As an occasional user I've found the Javascript debugging functions invaluable, and the ability to edit CSS in-place and see the results immediately has also been really helpful in debugging style sheets - in fact its biggest downside from my perspective is that it's not immediately obvious how to use many of its functions.

• Live HTTP Headers http://livehttpheaders.mozdev.org/ is a great tool for exposing the interactions between your browser and a server. I found this invaluable when I was debugging some website functionality that I was developing earlier this year, as it enabled me to follow a redirect that I'm sure I couldn't have seen otherwise.

• QuickJava http://quickjavaplugin.blogspot.com/ is a utility that allows support for Java, Javascript, Flash, Silverlight, images and others to be toggled on and off within your browser, enabling you to check how a page behaves when viewed by someone who doesn't have these enabled.
  

• I really like the HTML Validator http://users.skynet.be/mgueury/mozilla/ for ensuring that my HTML markup is actually W3C compliant; the main issue with this is that it's only available for Windows platforms. Provided you have the "Add-on Bar" visible in Firefox (toggle via "Options" in the Firefox main menu, or do ctrl+/), this displays a little icon at the bottom of the screen indicating the goodness or otherwise of your markup.

There are a few other useful add-ons for working with design elements like colours and images:

• Colorzilla http://www.colorzilla.com/ is a tool that allows you (among other things) to pick colours from the current webpage and get the corresponding hex codes or RGB values.

• Measureit http://frayd.us/ creates a ruler that lets you measure the size of page elements in pixels - particularly helpful when sizing images for web display.

• In the past I've found the in-browser screen capture utility Fireshot http://screenshot-program.com/fireshot/ quite handy for taking screenshots of an entire webpage including the off-screen portions. I have to admit I haven't used it for a while though. There's a paid "pro" version which offers a lot of additional functionality.
  

Although I've given URLs, the easiest way to install any of these is via the "Get Add-ons" tab accessed via the "Add-ons" option in Firefox's main menu (I'm using Firefox 8.0 at the time of writing). Once installed the individual add-ons appear in various places, for example by default Firebug's icon can be found at the top-right hand corner. If an add-on's icon doesn't appear automatically (as seems to happen for Measureit) then you might have to add it manually: go to "Options"/"Toolbar layout", locate the item and drag it to the toolbar.

I wouldn't try to argue that this is definitive list, but for an occasional user like as myself these tools work well and (with the exception of Firebug) are easy to remember how to use even after several months away from them. However if these don't meet your needs then I'd recommend checking out the "Web Development" category of Mozilla's add-ons site for many more options.

Creative Commons overview

A while ago I came across an interesting overview of the Creative Commons licence for digital content by Jude Umeh in the BCS "IT Now" newsletter ("Flexible Copyright", also available via the BCS website at http://www.bcs.org/content/conBlogPost/1828 as "Creative Commons: Addressing the perils of re-using digital content"), which I felt gave a very clear and concise introduction to the problem that Creative Commons (CC) is trying to solve, how it works in practice, and some of the limitations.

Essentially, anyone who creates online content - whether a piece of writing (such as this blog), an image (such as a photo in my Flickr stream), or any other kind of media - automatically has "all rights reserved" copyright on that content. This default position means that the only way someone else can (legally) re-use that content is by explicitly seeking and obtaining the copyright owner's permission (i.e. a licence) to do so. As you might imagine this can present a significant barrier to re-using online content.

The aim of the Creative Commons is to enable content creators to easily pre-emptively grant permissions for others to re-use their work, by providing a set of free licences which bridge the gap between the "all rights reserved" position (where the copyright owner retains all rights on their work) and "public domain" (where the copyright owner gives up those rights, and allows anyone to re-use their work in any way and for any purpose).

These licences are intended to be easily understood and provide a graduated scale of permissiveness. According to the article the six most common are:

• BY ("By Attribution"): this is the most permissive, as it grants permission to reuse the original work for any purpose - including making "derived works" - with no restrictions other than that it must attributed to the original author.

• BY-SA ("By Attribution-Share Alike"): the same as BY, with the additional restriction that any derived work must also be licensed as BY-SA.

• BY-ND ("By Attribution-No Derivatives"): the original work can be freely used and shared with attribution, but derivative works are not allowed.

• BY-NC ("By Attribution-Non-Commerical"): as with BY, the original work can be used, shared and used in derived works, provided attribution is made to the original author; however the original work cannot be used for commercial purposes.

• BY-NC-SA ("By Attribution-Non-Commercial-Share Alike"): similar to BY-SA, so any derived work must use the same BY-NC-SA licence, and like BY-NC, in that commercial use of the original work is not permitted.

• BY-NC-ND ("By Attribution-Non-Commercial-No Derivatives"): the most restrictive licence (short of "all rights reserved"), as this only allows re-use of the original work for non-commercial purposes, and doesn't permit derivative works to be made. Umeh states that BY-NC-ND is "often regarded as a 'free advertising' licence".
  

As Umeh points out, "CC is not a silver bullet", and his article cites examples of some of its limitations and potential pitfalls. Elsewhere I've also come across some criticisms of using the non-commercial CC licences in certain contexts: for example, the scientist Peter Murray Rust has blogged about what he sees as the negative impact of CC-NC licensing in science and teaching (see "Suboptimal/missing Open Licences by Wiley and Royal Society" http://blogs.ch.cam.ac.uk/pmr/2011/10/27/suboptimalmissing-open-licences-by-wiley-and-royal-society/ and "Why you and I should avoid NC licences" http://blogs.ch.cam.ac.uk/pmr/2010/12/17/why-i-and-you-should-avoid-nc-licences/).

However it's arguable that these are special cases, and that more generally CC-based licensing has a significant and positive impact on enabling the legal re-use of online material that would otherwise not be possible: indeed, even the posts cited above only criticise its NC aspects, and otherwise see the CC as greatly beneficial. Certainly it's worth investigating if you're interested in allowing others to reuse digital content that you've produced (there's even a page on the CC website to help choose the appropriate CC licence based on answers to plain English questions: http://creativecommons.org/choose/).

As I'm not an expert on CC (or indeed on copyright law or content licensing), I'd recommend Umeh's article as the next step for a more comprehensive and expert overview; and beyond that of course more information can be found at the Creative Commons website http://www.creativecommons.org/ (with the UK-specific version due to become available at http://www.creativecommons.org.uk later this month).

Day Camp 4 Developers: Project Management

Just over three of weeks ago I attended the third online Day Camp 4 Developers event, which this time focused on the subject of project management. The DC4D events are aimed at filling the "soft skills" gap that software developers can suffer from, and rather than being a "how-to" on project management (arguably there are already plenty of other places you can learn the basics) the six speakers covered a range of topics around the subject - some of which I wouldn't initially have thought of in this context (for example, dealing with difficult people). However as one of the speakers noted, fundamentally project management is as much about people as it is about process, and all of them delivered some interesting insights.

The first talk (which unfortunately I missed the start of through my own disorganisation) by Brian Prince about "Hands-on Agile Practices" covered the practical implementation of Agile process in a lot of detail. I've never worked with Agile myself, but I have read a bit about it in the past and Brian's presentation reminded me of a few Agile concepts that sound like they could be usefully adopted elsewhere. For example: using "yesterday's weather" (i.e. statistically the weather tomorrow is likely to be the same as today's) as a way to plan ahead by considering recent performance; and the guidelines for keeping stand-up meetings concise could also be applied to any sort status meeting (each person covers the three points "what I did yesterday", "what I'm doing today and when it will be done", and "what issues I have"). The idea of focusing on "not enough time" rather than "too much to do" also appealed to me.

The next presentation "Dealing with Difficult People" by Elizabeth Naramore turned out to be an expected delight. Starting by asking what makes people you know "difficult" to interact with, she identified four broad types of behaviour:

• "Get it done"-types are focused on getting information and acting on it quickly, so their style is terse and to-the-point,
• "Get it right"-types are focused on detail, so their style is precise, slow and deliberate,
• "Get along"-types are focused on making sure others are happy, so their style is touchy-feely and often sugar-coated, and
  
• "Get a pat on the back"-types are focused on getting their efforts recognised by others, so their style is more "person-oriented".

The labels are instantly memorable and straight away I'm sure we can all think of people that we know who fit these categories (as well as ourselves of course). Elizabeth was at pains to point out that most people are a mixture of two or more, and that none of them are bad (except when someone is operating at an extreme all of the time). The important point is that they affect how people communicate, so if you can recognise and adapt to other people's styles, and learn to listen to them, then you'll stand a better chance of reducing your difficult interactions.

Rob Allen was next up with "Getting A Website Out Of The Door" (subtitled "Managing a website project"), and covered the process used at Big Room Internet for spec'ing, developing and delivering website projects for external clients. Rob included a lot of detail on each part of the process, what can go wrong, and how they aim to manage and reduce the risks of that happening. One specific aspect that I found interesting was the change control procedure, which is used for all change requests from their clients regardless of the size of the change, essentially:

• Write down the request
• Understand the impact
• Decide whether to do it
• Do the work!

I think that the second point here is key: you need to understand what the impact will be, and how much work it's really going to be (I'm sure we've all agreed at one or another to make "trivial" changes to code which have turned out in practice to be far more work than anyone first imagined). A more general point that Rob made was the importance of clear communication, particularly in emails (which should have a subject line, summary, action and deadline).

Rob was followed by Keith Casey talking about how "Project Management is More Than Todo Lists". One of the interesting aspects of Keith's talk was that he brought an open source perspective to the subject. In open source projects the contributors are unpaid and so understanding how their motivations differ from doing work paid work is important for the projects to successful: as Keith said early on in his talk, in this case "it's about people".

He argued that people managing open source projects should pay attention to the uppermost levels of Maslow's Hierarchy of Needs (where the individual focuses on "esteem" and "self-actualisation"), but there was also a lot of practical advice: for example, having regular and predictable releases; ensuring that bugs and feature requests are prioritised regularly, and that developements should be driven input and involvement by the community. I particularly liked the practical suggestion that frequently asked questions can be used to identify areas of friction that need to be simplified or clarified. He also recommended Karl Fogel's book "Producing Open Source Software", which looks like it would be a good read.

Thursday Bram's presentation "Project Management for Freelancers" was another change of direction (and certainly the subtitle "How Freelancers Can Use Project Management to Make Clients Happier than They've Ever Been Before" didn't lack ambition). She suggested that for freelancers, project management is at least in part about helping clients to recognise quality work - after all they're not experts in coding (that's why they hired you), so inevitably they have an issue with knowing "what does quality look like?". (If you've ever paid for a service such as car servicing or plumbing then I'm sure you can relate to this.) So arguably one function of project management is to provide a way to communicate the quality of your work. The key message that I took away from Thursday's talk was that "what makes people happy is 'seeing progress' on their projects". Again I felt this was an idea that I could use in my (non-freelancer) work environment.

The last session of the day was Paul M. Jones talking about "Estimating and Expectations". Essentially we (i.e. everyone) are terrible at making estimates, as illustrated by his "laws of scheduling and estimates":

• Jones' Law: "if you plan for the worst, then all surprises are good surprises"
• Hofstadter's Law: "it always takes longer than you expect - even when you take Hofstadter's Law into account"
• Brooks' Law: "adding more people to a late software project will make it even later"
  

However there are various strategies and methods we can use to try and make our estimates better: for example, using historical data and doing some design work up front can both provide valuable knowledge for improved estimates. In this context Paul also had my favourite quote of the day: "It's not enough to be smart; you actually have to know things" (something that I think a lot of genuinely clever people can often forget, especially when they move into a domain that's new to them).

It felt like Paul packed an immense amount of material into this talk, covering a wide range of different areas and offering a lot of practical advice drawn from various sources (Steve McConnell's Code Complete, Fred Brooks' The Mythical Man Month and Tom DeMarco and Timothy Lister's Peopleware: Productive Projects & Teams were all mentioned) both for estimation techniques and for expectation management - where ultimately communication and trust are key (a message that seemed to be repeated throughout the day).

In spite of a few minor technical issues (the organisers had opted to use a new service called Fuzemeeting, which I guess was still ironing out some wrinkles), overall everything ran smoothly, and at the end I felt I'd got some useful ideas that I feel I can apply in my own working life - in the end surely that's the whole idea. It was definitely worth a few hours of my weekend, and I'm looking forward to being able to see some of the talks again when the videocasts become available. In the meantime if any of this sounds interesting to you then I'd recommend checking out the DC4D website and watching out for the next event!

Using Fedora 15 & Gnome 3: an update

Following up on my previous posting about the Fedora 15/Gnome 3 user experience, I've now been using it as a day-to-day working environment for the last 4 1/2 months and thought it was time to post a brief update.

Overall the experience has been pretty good (although I gather a lot of other commentators on the web wouldn't agree). For me the least satisfying aspect is still the automated workspaces/virtual desktops, closely followed by the default left-click behaviour of icons in the favourites sidebar. Both of these continue to catch me out from time to time, but I'd class their deficiencies as merely irritating rather than unusable.

Another aspect that I complained about in my previous post was the limited set of customisations that seemed to be available. However I've since discovered the gnome-tweak-tool, which provides access to a much wider range of customisations than is offered via the "Preferences" options. (This and many other useful features are covered in Fedora's release notes for desktop users, which I should probably have read right at the start.)

It's likely that you'll need to explicitly install it as it doesn't appear to be there by default, i.e.:

% yum install gnome-tweak-tool

(Nb this requires superuser privileges). To launch, start from the command line (or go to the "Applications" desktop view and use the search box to look for "tweak"). The tool itself looks like this:

Figure 1: gnome-tweak-tool displaying the "Fonts" tab

There are various categories ("Fonts", "Interface" etc) with a set of options for each, and at first glance there doesn't seem to be that many options available. However if the one you want might doesn't appear to be there then it's worth typing in some search terms to see if something comes up (for example, this is how I found the option for displaying the full date next to the time at the top of the screen).

Another useful utility is gnome-session-properties (again, seems easiest to launch from the command line), which really doesn't have many options but does allow you to customise which applications start up on login:

Figure 2: gnome-session-properties dialog

As you can see by the fact that I'm still using the default desktop wallpaper, I'm not big on customisations (in fact my needs are basic: web browser, email client, terminal window, Emacs and some development tools are usually sufficient), however these additional tools have helped make me feel a little more at home, and generally I'm pretty happy with the setup now.

Finally I thought I'd give the GnomeShell Cheatsheet page at http://live.gnome.org/GnomeShell/CheatSheet a quick mention. It covers similar ground to my previous post but from a more expert perspective and with some useful extra detail.

Book review: “Python Testing Cookbook” by Greg L. Turnquist

Disclosure: a free e-copy of this book was received from the publisher for review purposes. The opinions expressed here are entirely my own; a copy of this review has also been posted at Amazon.

Greg L. Turnquist’s “Python Testing Cookbook” explores automated testing at all levels, with the intention of providing the reader with the knowledge needed to implement testing using Python tools to improve software quality. To this end the book presents over 70 “recipes” in its nine chapters (ranging from the basics of unit testing, through test suites, user acceptance and web application testing, continuous integration, and methods for smoke- and load-testing), covering both tools for testing Python, and Python tools for testing. It also delivers advice about how to get the most from automated testing, which is as much an art as a science.

The first three chapters introduce the fundamentals: writing, organising and running unit tests, comprehensively covering unittest (Python’s built-in unit testing library), nose (a versatile tool for discovering, running and reporting tests) and doctest (which turns Python docstrings into testable code – a sample of this chapter can be downloaded from http://www.packtpub.com/python-testing-cookbook/book). Having established a solid foundation, subsequent chapters look at increasingly broader levels of automated testing using the appropriate relevant Python tools: for example, the “lettuce” and “should_DSL” libraries for “behaviour driven development” (an extension of “test driven development” which aims to produce human-readable test cases and reports), and the “Pyccuracy” and “Robot” frameworks for end-user acceptance testing of web applications. Later chapters cover higher level concepts and tools, such as using nose to hook Python tests into “continuous integration” servers (both Jenkins and TeamCity are covered in detail), and assessing test coverage using the “coverage” tool (both as a metric, and to identify areas that need more tests). A detailed chapter on smoke- and load-testing includes practical advice on developing multiple test suites for different scenarios, and methods for stress-testing (for example, by capturing and replaying real world data) to discover weaknesses in a system before going to production. The final chapter distils the author’s experience into general advice on making testing a successful part of your code development methodology, both for new and legacy projects.

There’s a lot of good stuff in this book: the initial chapters on unittest and nose are particularly strong, and I can imagine returning to these in future as a reference. There is also a lot of excellent and hard-won practical advice from the author’s own experience – not only in these early chapters but throughout the book – which is consistently valuable (in this regard the final chapter is a real highlight and could easily stand alone – I will definitely be re-reading it soon). Elsewhere the various tools and topics are presented clearly with plenty of useful detail, and in some cases have demystified things that I’d always assumed were quite esoteric and difficult to do (nose in particular was a revelation to me, but also setting up continuous integration servers and measuring test coverage).

There are a few disappointments: the section on mock objects left me feeling baffled as to how to actually implement them in practice – a shame as it was something that I’d looked forward to learning. I’d also have liked something about approaches for handling difficult testing scenarios such as software which interacts with the file system or with large files – a few hints here would have been invaluable for me. There are typos in some commands and code in a few recipes (e.g. for nose), which meant I had to look up the correct syntax elsewhere – perhaps not so bad, but annoying (especially in a cookbook) – and since the recipes themselves aren’t numbered, this sometimes made it difficult to navigate between them.

However these are fairly minor quibbles, and in conclusion I was impressed with both the breadth of material covered by the book and the level of detail for many topics. Moreover I enjoyed reading it and was often left feeling excited at the prospect of being able to apply the ideas to my own projects, which is I think was one of the author’s aims (and no mean feat for a technical book). I think that the combination of the detail together with the author’s practical advice make this book both an excellent introduction to testing with Python, and a valuable resource to refer back to subsequently.

(Addendum: Greg Turnquist's blog about the book can be found at http://pythontestingcookbook.posterous.com/ and features some interesting supplementary material.)

Fedora 15 and Gnome 3: user basics

I've been using Fedora 15 for about a month now and thought it was time to write up some of my experiences with the new Gnome 3 desktop, since certain aspects are quite a bit different from the previous version. I know other people have posted details about the Fedora 15 desktop (for example Xavier Claessens' One Week with Gnome 3) but when I first installed it there didn't seem to be much from a "user basics" perspective. So this is my take, hope it's useful.

Getting started

When you first start up Gnome 3 the desktop looks pretty empty - in fact there are no desktop icons in this new version (even when you put them in your "Desktop" subdirectory):

Figure 1: "Empty" Gnome 3 desktop on startup. No desktop icons allowed!

To get started, move the mouse to the word "Activities" at the top right-hand corner of the screen (the so-called "hot corner") - immediately changing the desktop to the "Windows" view:

Figure 2: "exploded view" of the Gnome 3 desktop, accessed either by moving the mouse over the "Activities" hot corner (top-left of the screen), or by hitting the "Gnome" (i.e. Windows) key on the keyboard. The Favourites sidebar sits on the left edge of the screen, and the edge of the Workspaces sidebar peeks out on the right.

In this view (figure 2) you can see the Favourites sidebar on the left side, and just the very edge of the Workspaces sidebar on the right (more about those below). I call this the exploded view of the current workspace, since (as in this example) features minatures of any windows in the workspace. The exploded view can also be toggled by pressing the "Gnome key" "Super key" (i.e. the Windows key).

From this view you can toggle to the "Applications" view, by clicking on "Applications" near the top left (figure 3):

Figure 3: "Applications" view of the Gnome 3 desktop

This shows all the applications installed on the system, with a search box and category groupings on the right to help you find the one you want.

• Drag icons from this view to the "Favourites" bar to make them more easily accessible in future.
  
• The "Add/remove software" application is a graphical front end to yum for installing and managing additional packages that are weren't included by default.

The Favourites sidebar: launching and navigating applications

The Favourites sidebar is the strip down the left-hand side which holds various application icons. These icons do "double-duty": if you've dragged an icon there from elsewhere (essentially "favouriting" it), then it initially acts as a launcher for that application; also the icons for any running applications (favourited or otherwise) will appear here.

If an application already has one or more instances running then clicking on its icon takes you to the "nearest" running instance; clicking-and-holding (or right clicking) gives you more options (e.g. to start a new instance, or move to any of the currently open instances) - behaviour that is probably already familiar to users of Windows 7 and Mac OS X (figure 4):

Figure 4: The "Favourites" sidebar with dialogue (i.e. the black bubble) opened for Firefox after right-clicking on its icon. This gives options to move to a running Firefox window, or to start a new Firefox instance.

Another way to navigate between running applications is to use Alt+Tab to cycle between them (figure 5):

Figure 5: Alt+Tab moves between running applications...

Repeated Alt+Tabb'ing moves between the applications; if there's more than one instance running then these are also shown when you Alt+Tab to it, and you can use the arrow keys to navigate to the specific one you want (figure 6):

Figure 6: ... and arrow keys allow you to select a specific instance if there are multiple instances of a particular application.

The Workspaces sidebar: navigating multiple desktops

Workspaces provide a way to manage applications, by giving the user multiple virtual desktops. These should already be familiar to seasoned Gnome users, but they operate somewhat differently in Gnome 3: there are no longer a fixed number of workspaces, instead they are created and destroyed automatically by the system as required.

You can move between workspaces in at least two different ways. Firstly, you can access the workspaces sidebar on the right-hand side of the screen, by moving the mouse over it in the "exploded view" of the desktop and causing it to "pop out" (figure 7):

Figure 7: the Workspaces sidebar "popped out" on the right of the screen in the exploded view of the Gnome 3 desktop.

The sidebar shows miniatures of each workspace, with the current workspace highlighted with a white outline. Clicking on one of the images takes you to that workspace; you can also drag application windows between the different workspaces.

Note the sidebar also shows an extra "empty" workspace at the bottom: if an application is opened or moved into this workspace then a new empty workspace is automatically created underneath. Furthermore, there's only ever one empty workspace - so if a workspace "empties" (e.g. because you've closed all the applications it contains) then Gnome automatically removes it. This can be quite disconcerting, and is probably the feature that causes me the most confusion in practice as it often upsets my sense of where I am in the workspace order.

The other way to navigate between workspaces is Alt+Ctrl+Up/Down Arrows, which I find myself using quite a lot (although I frequently overshoot into the empty workspace by accident) (figure 8):

Figure 8: moving between multiple desktops using Alt+Ctrl+Up/Down keys

Other observations

• Resizing windows: windows can be maximised by double-clicking on their title bar (double-click again to restore to the original size). There's no "minimise" button on the window frame, so you now have to right-click and then select the "Minimise" menu option. Also, note that dragging a window to the top of the screen automatically causes it to maximise (again similar to Windows 7, and not always what you intend). Manual resizing is also possible as always, by dragging the window edges - but this can be fiddly, as the area where an edge can be "caught" for dragging seems to be quite small.
  

• System notifications: these now pop up rather discreetly at the bottom of the screen, but interacting with then can be frustrating at times - often they disappear before you have a chance to read them, and sometimes (counterintuitvely) disappear when clicked.
  

• Customisation: while some preference-type options are available via the "username" menu (top right-hand corner of the screen) under "System Settings", overall the customisation options feel quite limited (for example, no screen-savers). However as a number of interfaces to system tools currently only seem to be accessible by launching from a command line, it's not clear if this a conscious design decision or whether more customisation options will be exposed in future versions.

• Fallback mode: this is a half-way house between Gnome 2 and Gnome 3, and is started by default on systems which can't support the full Gnome 3 experience (which appears to include virtual machines). However as it's much more like the old Gnome, if you really don't like the new version then you could try using fallback mode instead.

Conclusion

Having been using Fedora 15 and Gnome 3 day-to-day for a few weeks now, I'm now largely used to its quirks and finding it overall a perfectly serviceable working environment - for me the new workspaces model and the rather random system notification mechanism have proved to be the most challenging differences from previous versions. So while it may not suit everyone's tastes it's definitely worth trying (and hopefully the more egregious foibles will be ironed out in future versions).