Skip to content

Linux

Linux Journal Readers' Choice Awards

The Linux Journal has recently published the 2009 Reader’s Choice Awards.

GNOME was voted, by readers, as the “Favorite Desktop Environment” garnering 53% of the votes, with KDE in second place at 30%.

From the article:

During the past year, GNOME has reached majority rule status, with 53% of you electing it your favorite desktop environment. This trend is despite the breakneck development of KDE 4 during the past year. Although GNOME garnered only a few more votes than it did in 2008, KDE’s vote count slipped as you’ve warmed to Xfce, Fluxbox and Enlightenment. The long and influential coattails of Ubuntu can only make any presidential candidate green with envy.

Flattering words indeed!

Contrast that to the 2004 Readers’ Choice Awards:

Favorite Desktop Environment

  1. KDE

  2. GNOME

  3. Window Maker

For several years now, KDE and GNOME have finished first and second, respectively, with an ever-increasing distance between the two. This year, KDE received two votes for every one GNOME received. Window Maker holds on to the number three spot, beating XFce by a single vote. No one said “they all suck” this year, and the only write-in voter who expressed frustration said he might try to write his own environment.

(Emphasis mine).

I think the GNOME community should be very proud of the progress made within GNOME, which is reflected in these vote totals.

(Thanks to Claus on the marketing list for pointing out the latest Readers’ Choice awards).

Meet Snowy, Tomboy's best friend

Tomboy was one of the first GNOME products I contributed code (documentation) to. It also is one of my all time favorite apps and one I can’t do without on a day to day basis. Whether it’s jotting down ideas I don’t want to forget, to-do lists, or organizing the release plan for the next GNOME Journal, I always have a bunch of notes open.

A few weeks ago, I finally got around to trying to sync my notes via sshfs on my desktop and laptop. And, to be frank, it was a pain in the butt, and not documented well. It’s working, but I don’t think it’s working quite right yet.

Which is why I couldn’t be more excited for Snowy. Snowy is a web application for synchronizing, viewing, sharing, and editing your Tomboy notes online. Snowy will power the Tomboy Online service, and in addition to syncing your own notes online, let you also share and edit with friends.

Best of all, Snowy will be Affero GPL licensed – so if you want to run your own Snowy server and sync your notes there, you can! (It’s similar to identi.ca – laconica is the open source software that powers identi.ca, and you could run your own microblog server on laconica if you wanted to).

I recommend reading Sandy Armstrong’s (lead developer of Tomboy) blog post on Tomboy and Snowy (including an early screenshot), and Brad Taylor’s (lead developer of Snowy) blog post introducing Snowy. (And the title of this blog post is stolen right from Brad’s mouth).

More to come!

GNOME.org revamp

After lots of stops and starts over the last few years, which really isn’t worth recapping, the GNOME web team is moving forward with a new www.gnome.org.

After lots of chatter on the gnome-web mailing lists the last couple months, Lucas organized a meeting, a set of tasks to be completed, and the timeline.

Personally, I’m helping with the content team – do we have the right pages for the new www.gnome.org? Is the sitemap correct with how those pages flow? From there we’ll work on adding the content, and then editing.

Want to help? This is a great area to jump in and help – you don’t have to know how to code, just help us write some paragraphs!

Join the GNOME Marketing mailing list and get involved!

GUADEC!

I’m going to GUADEC this year!

In all my travels, I’ve visited almost all 50 states in the U.S., but I’ve never travelled internationally. Now in the span of 30 days, I’ll be visiting both Canada and Europe – and both are related for GNOME events. And I’d like to say a big thank you to GNOME for helping subsidize my travel to both events.

The initial GUADEC schedule was posted this morning, and I’m excited (and nervous) that Stormy’s and my Birds of a Feather session on GNOME marketing was accepted! (Thursday, 10:00 a.m.). I was hoping to fly back home Friday morning, but now I need to find a way to stay to see Davyd‘s talk on Documentation Friday morning.

In related GUADEC news, we at the GNOME Journal are publishing a GUADEC special edition. Are you going to GUADEC? Have an interesting idea for an article – maybe from a talk you want to attend to learn about (and share about with the GNOME Journal audience!) or someone you might want to interview face to face while at Gran Canaria? Let us know, more info is available here.

I’ll be seeing you in July in Gran Canaria.

GNOME Journal Issue 14 released!

Just in time for your weekend reading pleasure, for the first time since December 2007, a new GNOME Journal has been published!

Articles featured include:

I’m especially proud of this issue, as it is my first herding cats as release coordinator. I’ve written an article and edited others before, but this is my first one as a major contributor to the team.

What are you waiting for? Go read it now!

GNOME Updates

Lots of stuff going on in the world of GNOME for me!

Attended a few meetings last week with GNOME related projects.

This past Sunday, April 19th, the Documentation team met for the first time in a while. Shaun gave an update on the status of Mallard, the new markup language for GNOME Docs; a possible change to how we license docs; an introduction to Pulse and some brainstorming on new ways to bring guides to users.

On Tuesday, the Tomboy team met to discuss the road to a 1.0 release. More exciting though is the news on the work being done around syncing for Tomboy, including a potential online syncing service for users. As someone who’s lazy, and not that technical, but owns multiple computers that use Tomboy, I’m very excited about the potential a syncing service has. (And if you want to help update the Tomboy end user website, please let me know!)

Related to the Documentation news though, I’m happy to announce I’ll be attending the first ever Open Source Documentation conference, Writing Open Source, in June in Owen Sound, Canada. The GNOME Foundation is graciously covering my lodging, and three other GNOME Documentation team members, including Shaun, will be there. In addition to the tracks on Friday, there is an unconference on Saturday, and we will be having a documentation hackfest on Sunday. The hackfest might also be the first public unveiling of Mallard as we start working on all new documentation for GNOME 3.0.

I booked my flight and paid for the conference this weekend, now comes the hard part – the waiting until June.

KVM & Virtual Machine Manager in Foresight

Foresight has long been a proponent of KVM over other virtualization technologies such as Xen or Virtualbox.

If you, like me, aren’t a guru on the command line and prefer using a GUI, Virtual Machine Manager is available in the Foresight repositories. If you’ve used Virtualbox or VMWare, you’ll find virtual-manager very familiar. The only downside (for some), is that you will need a modern processor that supports Intel VT or AMD-V.

Let’s get started:

In this example, we will use an ISO of a Linux distribution. Go ahead and download an ISO of a Linux distro you’d like to try out.

From a command line install the tools you’ll need:

sudo conary update virt-manager libvirt

You’ll want to install it from the command line, as PackageKit has a bug that it doesn’t pull in libvirt:runtime for some reason. (FL-2050)

Start the service:

sudo service libvirtd start

Go to Applications -> System Tools and choose Virtual Machine Manager.

PolicyKit will prompt you for your password. Enter it and Virtual Manager will start.

Click on localhost.

Then click File -> Add Connection and click Connect.

Click New in the bottom right hand corner. You will be prompted to enter the name of your new Virtual Machine.

You will now be present with 5 steps to create your Virtual Machine:

Step 1: Enter the name of VM you wan to create

Step 2: Click on “Use ISO Image” and then “Browse” and chose the ISO you downloaded earlier. Then from the drop down boxes choose Linux, and in the second drop down box you can check if the distro you’re trying is available.

Step 3: Choose how much RAM and how many CPUs the VM can use

Step 4: The defaults should work – choose to enable storage, and how much hard drive space the VM can use. (I’ve learned that hard drive space is important – these VMs need more than you think they will!)

Step 5: The defaults should work here as well, but you can click on Advanced Options if you want to change the Networking options. I’ve never had to change anything here, and Networking has worked out of the box.

And that’s it! Now under “localhost” double click the name of the VM you created, and it will boot up, just like a computer was booting up. You’ll install the Linux distro, just like you would on to a hard drive. One thing I’ve noticed, is that after an installation, it needs to reboot. My experience is the VM shuts down, rather than rebooting, but just starting it up again, the VM will boot up th eOS after your install.

To use the mouse, just click your mouse inside the virtual machine. To regain control of your mouse, press control and alt and your mouse will work normally inside Foresight again.

Here is a screenshot of Virtual Machine Manager running while the GNOME Dev Kit loads (note I have created VMs for the Dev Kit and the betas of Fedora 11 and Ubuntu 9.04:

GNOME Dev Kit

This screenshot shows the GNOME Dev Kit and Fedora 11 running side by side (One interesting thing about running Fedora is that i don’t have to release the mouse via ctrl-alt, it’s automatic within the OS. I’m not sure why, maybe it’s because Virtual Machine Manager is developed by Red Hat?):

Virtual Machines

If you have a modern processor, the hard drive space, and some memory to spare, I highly recommend Virtual Machine Manager. It makes creating and running different operating systems a breeze.

Writing GNOME Docs, Part II

So you’ve decided you want to contribute to GNOME and write some documentation. In Part I, I wrote about the steps I went through to prepare to write GNOME documentation and picking a project.

In Part II, we will take a look at the final preparation stage, including checking out the project’s source code via GNOME Subversion and finding documentation that needs updating. I am still fairly new to the process myself, but these are some of the steps I take in writing documentation.

Part III will cover updating the Docbook XML file, reviewing your changes and submitting a patch with the updated docs.

Now that you’ve picked a project to work on, I recommend subscribing to the project’s mailing list, and, if they have one, hang out in their IRC channel. A list of all GNOME mailing lists is here, and be aware of the GNOME Code of Conduct when sending an email to a list.

Personally, I recommend letting the project or lead developer(s) know you want to help out. This is helpful for a couple of reasons, including:

  • If you, like me, are new to contributing to GNOME, you probably don’t have SVN access to commit your changes. A developer on the project, or a member of the GDP if you’re working on a project the GDP can commit, will have to submit your changes to the project.
  • You might have a question on how a feature works, and want clarification. If you’ve introduced yourself, other project members will understand why you’re asking.
  • Help is always appreciated! You have nothing to worry about – almost all projects will welcome you with open arms. Especially doc writers, as it sometimes considered unglamorous work.

As I mentioned in Part I, I’ll be working on the Tomboy documentation, and I sent an email to the list letting the developers know, and asking if there were any areas of the docs that also needed changes or updates. (The Tomboy mailing list is generating a 404 error when I try and click on my email which can be found here).

In a terminal, create a directory where you will to checkout the source code of the project too. GNOME uses Subversion, and will be moving to git in the future. The GNOME Wiki has a great page on using Subversion. Move to the directory where you want the source code, and per the GNOME SVN wiki page, checkout the project:

svn co http://svn.gnome.org/svn/[module]/trunk [module]

For Tomboy, I would do:

<br /> svn co http://svn.gnome.org/svn/tomboy/trunk tomboy

The Tomboy source code is now checked out to the “tomboy” directory in the directory I’m currently in. For the purpose of this example, we will assume you checked out the source code to $/home/source/tomboy

Now it’s time to find some documentation that needs updating. Good sources to find documentation updates include:

  • Projects’s Bugzilla
  • Reviewing the projects current documentation
  • Project’s release announcement of new features
  • Mailing list

I recommend starting by doing a query in the project’s Bugzilla (bug tracker) and see if any users have filed bugs or requests against the project’s existing documentation.

Log in to GNOME Bugzilla, and click the “Browse” button in the top menu. On the Browse page, click on the drop down menu next to “Browse:” and click on the project you want to view, and “Show product”. You will be taken to the project’s Bugzilla page, which provides an overview of the number of bugs, type, and severity, among other information.

In the search box towards the top, you will see “project:Tomboy” already entered (or the project you chose), after that type documentation and hit search. The results will show any bugs that have a keyword of documentation, and you can browse through any open bugs to see if there are any changes that need to be added to the project’s documentation.

You will want to keep notes of any bugs you come across, or changes and updates the documentation file needs. Ironically, Tomboy is a great tool for this, and even supports the ability to drag and drop a GNOME Bugzilla link from your browser into Tomboy and converts it to an easy to use link.

I also recommend reviewing the project’s current documentation. Open the application, and hit F1 to bring up the help in the GNOME Help Browser (Yelp). With GNOME being on a 6 month release cycle, it may be possible that new features were added without being documented, which is why it’s also helpful to see if there was a Release announcement that outlines those new features.

Review the sections in the documentation, and compare to the behavior of the application. Do they match? If not, it might be useful to ask the developers in IRC or on the mailing list to double check, and make a note that the documentation needs to be updated to reflect those changes. This process can be time intensive, which is why you may want to start working on documentation with an application you’ve used and are familiar with.

If you introduced yourself on the project’s mailing list, the community members may have pointed out some areas that need updates as well.

Hopefully this has helped in getting you ready to (finally!) update the documentation. In Part III, I’ll cover updating the documentation’s Docboox / XML file and submitting your changes to the project.

Writing GNOME Docs, Part I

It’s been just over a year since I submitted my first patch to GNOME, for updated Tomboy documentation.

In that time, Shaun McCance of the GNOME Documentation team has been doing a lot of work to make it easier to get involved with the GNOME docs team.

Though Shaun is trying to make it easier to see which projects might need help with documentation updates, it’s still kind of overwhelming to try and figure out where to get started, especially as some of the information on the GNOME Docs team is outdated.

The Docs Team page on the GNOME wiki is a great place to start. Let’s take a look at a number of the steps it lays out, and I’ll try out point out where, in my opinion, some of the important steps lay and additional tools available, such as Pulse.

Step 1 & 2: Join the mailing list and IRC, as it refers to.

Step 3 & 4: Choose a project and document to work on. First, you should choose a project that interests you, and that you may know a little about. Here is a quote from Shaun McCance to the GNOME Docs mailing list on 5/8/08:

My general recommendation to new writers is to pick

an application manual for something you use frequently.

It’s easier to write documentation for an application

you’re familiar with. Smaller manuals will allow you

to go through the entire writing process and actually

finish something. Finishing things feels nice.

The good news is that this is one area Shaun is making easier with the Pulse project. Pulse isn’t officially released yet, and is run manually by Shaun. Pulse tracks all of the software in GNOME, including documentation and translations.

In January, Shaun sent an email to the GNOME Docs list that helps understand this process better, especially as it relates the GNOME 2.26 process, and with some updated steps that aren’t covered in the wiki:

When looking for documentation to work on, you can use Pulse to help sort:

Use Pulse to view all GNOME 2.26 documentation: [http://www.gnome.org/~shaunm/pulse/web/set/gnome-2-26-desktop#documents

]5

Pulse can show which docs don’t have a specific individual as a maintainer, and will display GDP (GNOME Documentation Project) if it doesn’t. It’s recommended to start with a document maintained by the GDP to work on. Follow this link: http://www.gnome.org/~shaunm/pulse/web/team/userdocs#documents and click on “Maintainer”. That shows the list of all projects maintained by the GDP. One of the advantages of working on a document maintained by the GDP is once your documentation move to the final state, the GNOME Docs team can commit the changes for you, as they are pre-approved with the maintainers of that project.

For my example though, wanting to update the Tomboy docs that I worked on a year ago, Tomboy is not maintained by the GDP. That’s ok – I’ve worked with one of the lead developers before, and I let him know in IRC that I was going to being working on documentation.

Going back to the Pulse list of documents, and clicking all, I then will choose and click on Tomboy.

Looking at the upper right hand corner of the Tomboy page in pulse, you will see:

Release Info

Status:

None

Familiarize yourself with the Status definitions that Pulse will display: http://live.gnome.org/DocumentationProject/StatusTracking

None – great! This is the document I’ll start working on as no one has started working on it yet.

Step 5: Going back to the GNOME Docs Wiki, step 5 is familiarizing yourself with the GNOME Style Guide.

The sections I found most useful, was Chapter 1, Fundamental Concepts, especially the sections on Tone and the Golden Rules. Chapter 7, Writing for GUIs, is good to cover as well.

When it comes to writing Docbook though, the best advice I can give is to jump in to a document – you’ll quickly learn the syntax with or without prior programming experience. I have zero programming experience outside of some very basic HTML , and by looking at a couple of different pieces of GNOME documentation, was able to write the Foresight User Guide in Docbook.

Steps 6 & 7: Create accounts in GNOME Bugzilla and the GNOME Wiki (aka live.gnome.org).

The only other advice I can give, especially as it relates to IRC and the mailing list, is to drop a note and introduce yourself, and let the community know you want to help out. All of this might sound complicated, but instead of spending hours wading through all of the documentation and webpages available (some of it really out of date), I think if you read the above steps it will start to make sense (at least it did for me!)

In Part 2, I’ll cover my experience in some of the basics around using SVN to check out a project, updating the status and the documentation, and submitting a patch.