http://blog.linuxgrrl.com

Actually, I tried to do this maybe a year ago and gave up because there was some issue with the feed getting cut off in Planet. I’ve got a new version of WordPress running and after testing the feed with Planet, it seems to work fine so I’m going for it.

If you’re following my blog via RSS, the new feed URL is:

http://blog.linuxgrrl.com/feed

I really appreciate the time folks take to read my ramblings here, and I am very sorry if this move causes you any annoyances.

Computers should change peoples’ lives for the better and software freedom is an essential component in doing that. Making Fedora easier to use, I believe, will help because I think Fedora’s values lead to the right approach in meeting our essential need for software freedom.

Fedora doesn’t follow a model of:

1. Get lots of users!
2. ?????
3. PROFIT!

I don’t think the ultimate goal of Fedora is world domination, either. I think it’s world collaboration. The end game isn’t to get as many users as possible; it’s to get as many productive contributors as possible to all free software and free culture. This is pretty well reflected in Fedora’s vision statement:

The Fedora Project creates a world where

• free culture is welcoming and widespread,
• collaboration is commonplace, and
• people control their content and devices.

So this is a picture that I think represents what you work on if you work on Fedora. If you consider yourself a Fedora contributor, you’re involved in enabling other folks to succeed in least one of these areas (My apologies for components which may be represented out-of-scale):

(Inkscape SVGZ source)

The widest chunks are using Fedora and contributing.

Use Fedora is wide because we need to build, maintain, and improve on Fedora the OS itself to deliver free software; this is the day-to-day work of upstream and downstream developers, QA, and packagers. It’s also the day-to-day work of folks who support those who use Fedora; release engineering and infrastructure in delivering updates, the documentation team and folks in the forums and IRC who help users.

Contribute is wide because we need to support the folks who develop, build, test, design, market, and spread Fedora the OS – they need infrastructure to realize their goals, they need communication channels, they need tools, they need motivation and support.

Now, you could immerse yourself in the cycles of using and contributing. You could. Honestly, many folks do this day-to-day and leave the other pieces to other teams (marketing, websites, ambassadors, events, etc.) That’s fine; it’s a large complex system and you can’t worry about all pieces at all times. I do not think you can just drop the outreach portions of this system, though – leaving it to chance and not thinking at least a little about a strategy for which users you want to recruit and why. I worry a lot about this. Without exposure to ideas from fresh faces, without sanity-checks, and without new recruits to replace the turnover, I think you either shrink over time or stagnate. Either in our case would negatively impact our ability to recruit more contributors, our ultimate goal:

(Inkscape SVGZ source)

This idea has been illustrated and discussed previously, in slightly different forms in the Fedora community before. Basically, we should actively and strategically recruit new folks into our community to grow our userbase and thus our potential contributor base.

Achieving the mission sustainably

The Fedora Project Board has over the past few years done a lot of work to define Fedora’s strategy, including its user base and basic goals:

• Defined the mission of Fedora.
• Documented the values of the project.
• Defined the objectives of Fedora.
• Formed a vision.
• Defined a user base. (I do worry that different folks interpret the user base differently, I have my own interpretation.)

Fancy-pants documents! You might think we then all set them upon the fireside trophy shelf^W^W^W wiki, revel in a job well done and how fancy our pants are, and move on with our lives. Actually, these are documents that we can use to make decisions about how to keep our community sustainable, and how we should pave the way for new users and contributors to get involved in the project. What – how? Here’s a few examples, one hasn’t happened yet, one has, one is in progress and is the topic for the rest of this post:

• Alex Hudson started the Fedora Welcome SIG initiative, to “work on the ‘new user experience’ for those people coming to Fedora for the first time.” Using the user base as defined by the Board, the Welcome SIG could talk to various members of that user base, get feedback on their initial encounters with the Fedora community, create a list of the issues identified, and start formulating plans to attack them. I could see this SIG acting as a cross-functional group that coordinates improvements on the beginner user experience with the teams responsible for each of the components involved.
• The Fedora website redesign, which began in 2009 and was coordinated with the Fedora project board, was part of the rationale for designating a user base with which the redesign work could take place. The target user was referenced frequently throughout the design process and understanding who we were designing the page for helped us make decisions about how to structure the site and the kinds of information that needed to be on it (and what didn’t belong there!)
• The installer UX redesign, to which the rest of this post is devoted.

Here’s that diagram again:

(Inkscape SVGZ source)

If you want people to try Fedora so they can use it and so they can eventually become a FLOSS contributor, they need to be able to find and download it in the first place. The Fedora websites team and design team, with the website redesign project, hopefully made it easier for our user base to find the right download and to obtain it via our website.

Helping our user base access the installation media isn’t enough, though. They have to be able to make it through the installer to the other side! Those gaps in the diagram – each of those is a bail-out point. If they can’t make it easily through the installer, a member of our user base may well give up on Fedora.

So there is a very long justification for examining Fedora’s installer, but hopefully the backstory and context here gives you a better understanding of the approach to the design process that follows.

The Anaconda UX redesign – some history

The basic gist

So Fedora’s installer, Anaconda, is something we talked about a complete UX redesign for this past January at FUDcon Tempe. While we ended up getting a little stuck on the spins aspect towards the end, Will Woods brought up an idea during our brainstorm that led us to this:

I think is pretty brilliant of him to have led us this way, which is essentially a hub & spoke model for the UI. (Since I’m telling this tale in chronological order, you’ll have to wait for more details on this brilliance later.)

After FUDcon Tempe, I thought it would be a good idea to both understand where the installer is at today, and explore a bit about where we might want it to go.

Where the installer is at today

The installer today is a linear, wizard-style interface with many screens (depending on the path you choose, and if you count the firstboot and TUI screens you might encounter ~30 screens). Once you accept the partitioning scheme, you’ve gone beyond the point of no return and you can’t go back in the installer. So there isn’t a way to get an overview of all of your choices before pulling the trigger. Below is an (quite aged at this point) diagram of the installer flow sans firstboot from Fedora 11 so you can get the gist:

To understand where it was at (which was at the time, pre-F15), we did a couple of things:

• A screen-by-screen walkthrough of a typical DVD install process
• A screen-by-screen walkthrough of a typical Live Media install process (quite different from the DVD)
• An analysis of the screen-by-screen walkthroughs, comparing the DVD install process to Live Media and raising questions that came up about each process with the answers documented.
• notting catalogued the various timezone sources available to us and wrote up some of the issues in the current timezone dialog; I put together some mockups for some idea on how to lay the screens out which I kind of don’t like very much anymore. Both are on the Anaconda Location Whiteboard.

Some early design work happened as well:

• Looking at some of the things that came up about syslinux, I put together some mockups for improvements in the syslinux layout that precedes the installer, and hpa from syslinux upstream helped me figure out how to theme it all to have a clean look. There’s a pretty in-depth writeup here.
• The Anaconda Comic (part 1) was put together. The thought was mocking up a potential user experience for Anaconda in terms of a comic strip with a user’s narrative and goals could help us think through the experience without getting bogged down in individual screen layout and details. I’m not so sure it turned out to be a useful tool, though.
• Luya worked on some visual design ideas.

So leading up to and since FUDcon Tempe, a bunch of exploratory kind of design work and thinking has been going on, but we didn’t really reach a full coordinated design effort yet.

Kicking off a coordinated design effort

So the installer UX redesign is currently planned for Fedora 17. Fedora 15′s out – time to get cranking. Maybe 2-3 weeks ago, Chris Lumens told me we should ramp things up again, so I’ve been working with the design team (including a couple of new UX recruits!) on an overall plan of attack with some execution thus far.

The Anaconda UX redesign plan

The hub & spoke model

So our current thinking, right now (which generally occurs both in the #anaconda IRC channel as well as the on the anaconda-devel mailing list) is that we would use a two-hub hub & spoke model for Anaconda’s UI:

• Since the UI is rather useless if you can’t read it, we would start out with a language screen where you can pick out your language in its native name.
• Next, you’d be brought to the install summary hub (hub #1). This hub will have sane defaults everywhere where possible (we’re not sure on the storage section yet) with the goal that you could just skip diving into any of the options, press continue, and get a usable install (again, not sure on how storage works there ) The spokes of hub #1 are choices like keyboard layout, storage, date & time, install source, and Fedora flavor.
• Once you click continue on hub #1, you’ll be brought to the install progress screen which is also the personalization hub (hub #)2. This hub has an install progress bar along the bottom, and a series of rotating banners (‘ransom notes’) above that. The hub will have personalization options in it by default – the stuff you get asked in firstboot like if you want to register for smolt, what you want your user name to be, etc. It could also have OEM or other custom modules. You can completely skip filling any of this stuff out and go get a sandwich (or hot dog.) When the install is complete, you may reboot.
• When you reboot, if you filled none of the personalization hub options that we need to know, you’ll be presented with them again as a firstboot experience (we kind of need to know your username to make you an account, for example.) If you did fill out what we needed to know in anaconda, we won’t show you firstboot and you can get straight to business using Fedora.

What is pretty cool about this model is that if we’re able to pick the settings for hub #1 right (and yet again, not sure if that’s possible without breaking storage out into another screen), you could skip all of the options in the hub, click continue, and get a sane install. It essentially lets you skip multiple screens in one click. It also serves as a review or inventory of everything you’ve chosen, making it easy to skim over everything and dive down and modify something before pressing go. To change something you already selected in the current linear installer interface, you have to go “back… back… back…. back….” and sometimes you hit a, “back… back… oh crap, I can’t go back past this point” type of situation.

We also have a tension in designing for Anaconda that it does not only serve as the installer for Fedora, it serves as the installer for other distros with different user bases such as CentOS, Red Hat Enterprise Linux, and Scientific Linux. Users of those distros are more likely to care, for example, about specialized storage devices that most Fedora users probably don’t even have access to or care about using in an install. The hub and spoke model is a compelling approach here I think because we can serve Fedora’s users who might not care to tweak EVERY knob available by providing clear overviews with the option to dive in a level deep where they have interests. For users who must access very particular granular knobs to achieve their goals, though, they still have access through progressively deeper dives down a particular spoke.

Well, that’s all of our latest thinking. It could change. It’s a design. If we discover through some user research, for example, that some idea here is problematic, or if we run into a technical snag, the gist of our design described thus far may change. That’s okay. We want our installer to rock!

The design process

I´m serving as the lead designer of the project, with some help from other Fedora design team members:

• Joseph Reni (gejoreni on IRC), has put together a draft user research plan for both an informal study interviewing users and a more formal observational study sitting in front of a system running through an actual install. Please send him your thoughtful feedback and encouragement!
• Owen Coutts (ocoutts on IRC) has started working with us on the mockups and developing user stories. He’s spent some time surveying several OS installers including Windows and Apple’s to help inform the design process and to see how other OSes handle the process.
• Elad Alfassa (elad661 on IRC) who is already a rockstar on the websites team and a
  Hebrew translator for Fedora; he´s been reviewing the mockups from a localization POV as well as helping with the storage section. He’s been cranking out some serious hub & spoke mockups with me and asking the Anaconda devs tons of questions and generating a lot of great discussion.
• Luya Tshimbalanga (finalzone on IRC) who has done some good work on visual design for the installer on the past and is going to help us with that aspect of the process.

This is a huge project and I think a lot of issues and edge cases will come up as we least expect it. The approach I’ve proposed to the team is:

• Myself, Owen, Elad, and Joseph as he has time/interest will continue building out a full set of screens in the hub and spoke design. This is the latest PNG mapping of the screens; the SVG sources are in the same directory.
• As any of us designers run into issues/questions or need feedback on our mockups, we´ll pop into #anaconda for discussion/brainstorm.
• As discussions / brainstorms happen in IRC and here on-list, I´ll try my best to distill them into notes that will be added to https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Discussion so we don´t lose any of the decisions we make / rationale discussed (and I’ll save the IRC logs to the ‘Notes’ directory in the repo)
• Once we have a complete set of mockups, the set will be marked draft 1 and we’ll start writing up a spec / design document for it (<like what was done for the storage UI mockups).
• Joseph will continue working on a user research plan and as his data comes in all of us can pull it in and apply it to our latest thinking & designs.
• As necessary, we’ll compare the list of user complaints gathered on the main Anaconda UX Redesign wiki page, potentially also going through Bugzilla, to make sure the mockups cover or at least have a story for
  the user issues, noting issues we still need to work on.
• As necessary, we’ll also print out the mockups and do additional user testing on them (likely using a paper cutout method), noting identified issues.
• As necessary, we’ll also blog the mockups & design process to get additional feedback from you all!
• As we address issues uncovered in user testing and user complaint review, we’ll release additional drafts of the mockup set. Based on the storage mockups process, we may hit 6 or 7 drafts.

Following the brainstorming and the overall process

So the action is taking place here on a number of fronts.

• Anaconda’s IRC channel has been having many pretty lively discussions about this design; both myself and Elad have been pestering the developers with lots of questions and we’ve all been brainstorming together. We’ve been trying to keep a summary / distillation of these discussions available in the wiki because we want our decisions well-documented for later reference: https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Discussion
• Anaconda’s development mailing list has a thread that was started last Friday that’s still going on, so you might want to follow along on that list.
• Our main UX redesign wiki page (at https://fedoraproject.org/wiki/Anaconda/UX_Redesign is a bit messy at the moment but I’m hoping over time we’ll get it in order. It has many of the documents referenced in this post and more, and is really the main hub of our design documentation.
• We have a design repo which is a shared file space Elad, Joseph, Owen, Luya, and I are using to collaborate on mockups (via Sparkleshare). Mockups will land here first, before we use them to put together spec documents (like this one.) If you’d like to use git to pull it down, you can clone: git.fedoraproject.org/git/fedora-ux.git

Okay, okay. Wow, that was long. But it sounds cool. How can I help?

If this sounds like an interesting project and you’d like to get involved but aren’t sure how, here are some ideas. These are all things that would be very helpful for us that are probably a good way to get started in on the project:

• Review Joseph’s user research plan and give him some constructive feedback and encouragement!
• Send Joseph any questions you think he should be asking folks in Fedora’s user base. Send him your research questions as blog comments and he’ll be happy to integrate them into his plan.
• We need ideas for good ransom notes. We’re going to try to bring back the concept of ‘ransom notes’, little rotating banners that display while the install progresses. An oldie-but-goodie beloved by many is shown below as an example. We’re looking at potentially a 750 x 120 px format.
• Participate in our brainstorms on the anaconda-devel list or in the anaconda IRC channel, but please, keep it civil and constructive!

Inkscape SVGZ source

Note: just the blogs.fedoraproject.org hosted blog system is being retired. Planet Fedora is of course alive and well and will be sticking around!

Nooooo!! Why???

(Queue Darth Vader noooooo? )

There’s been a number of factors that lead the Fedora infrastructure team to decide to retire the service.

Fedora infrastructure team hackfest in the FUDcon Tempe hotel lobby

At FUDcon Tempe this past January, the Fedora infrastructure team had a face-to-face meeting/hackfest to discuss future direction for the team. While the Fedora community continues to come up with great new ideas for Fedora that involve an infrastructure component, including many of the ideas in ‘The Next Big Fedora Engineering Project’ session lead by Spot, there’s a lot of pre-existing infrastructure – some not actively used – that is currently being maintained by Fedora infrastructure team members. The more infrastructure on the team’s maintenance plate, the less cool new projects involving infrastructure that we can easily do as a community.

Fedora infrastructure team hackfest in the FUDcon Tempe hotel lobby

At the infrastructure team hackfest, which I listened in on while occasionally wandering off to get awesome photography tips from Tatica, this is a point that kept coming up – how is the infrastructure team going to support these new proposed services with everything we already have on our plate? Could the team re-evaluate the currently-maintained services, get an idea of how actively they are being used, and retire the least-used services to free up the team’s time to better maintain the most actively-used services and clear a path for taking on more new and innovative ideas?

Smooge documented this outcome of the Infrastructure hackfest in a blog post back in February, after FUDcon Tempe. Since that session, Nirik, Smooge, and others on the Fedora infrastructure team have been taking a look at all of the services running in Fedora, researching how people are making use of them, and trying to evaluate which ones might be reasonable candidates for retirement based on their usage and maintenance burden (among other attributes I’m sure.) A couple of months ago, for example, I received an email from Nirik asking about my usage of the hosted Zarafa instance Fedora infrastructure is maintaining. You may have received such emails about particular Fedora services you make use of.

So, just like other services Fedora infrastructure runs, the hosted blogs service came up for evaluation. The rationale for the decision to retire the service includes the following usage statistics:

• There are 92 blogs total on Fedora Blogs. This is a really small percentage of the total Fedora account population.
• Only 39 of those blogs have more than 5 blog posts.
• Only 23 of those blogs have made a single post in 2011. (The users of these blogs will be emailed a notice shortly.)
• Only 6 of those blogs have made any posts in the past month.

Besides the lack of wide usage, there are other factors that come into play here:

• The infrastructure team does not currently have a ‘champion’ or committed maintainer for the blogs system. If they did, even with the other reasons for retiring the service, the blogs system might still be kept running.
• Fedora blogs are running a fork of WordPress called WordPress MU, and the version it’s using is no longer supported. It would be a big effort to upgrade and migrate over to a new version.
• WordPress tends to have a lot of regular security updates, making it a bit more high-maintenance than other webapps. (Having tried and giving up on maintaining my own WordPress instance, this fits with my experience.)
• There are many good free & open source blog systems around, and many providers of them. For example, GNOME provides blog accounts via a hosted WordPress MU instance, and many Fedora contributors have their blog instead hosted over there. WordPress.com also provides free WordPress blogs; LiveJournal with its free & open source codebase also tends to be popular. Many Fedora contributors are also tech-savvy and maintain their own domain, on which they may prefer to maintain their own WordPress instance (this gives you a better ability to use a custom theme, for example) or their hosting provider may provide them access to free blog hosting (My hosting provider provides WordPress, with automated security updates!). A quick scroll through the planet feed listing on planet.fedoraproject.org shows all of these options in use by Fedora community members.

Given that the service isn’t really widely used, is high-maintenance compared to other services being provided, it’s easy to get free access to free & open source software that provides the same service, and that there’s no champion for the service (which could negate the other factors if he or she existed) – it appears the Fedora infrastructure team made a careful and reasonable decision.

Okay, since my blog is going away, what do I do?

If you’re one of the 20 or so folks actively using Fedora blogs, you may be wondering what your options are. Well, WordPress.com has a great free hosted service, and since Fedora’s blog system is WordPress, your blog entries should import over nice and cleanly. Here’s how to do it:

1. Log into Fedora blogs. Log into blogs.fedoraproject.org using your Fedora Account System username and password. You maydo this by clicking on the ‘Log in’ link in the lower left of the page, in the ‘Meta’ section. (Note: if you’re already logged in, the ‘Log in’ link will say ‘Log out’ – don’t click it, you can simply skip this step.)
2. Go to your blog’s dashboard. After log in, you should be brought to your blog’s Dashboard screen. If you’re already logged in and on the front page of blogs.fedoraproject.org, click on the ‘Control panel’ link in the lower left side of the page in the ‘Meta’ section.
3. Load the ‘export’ tool. In your dashboard, click on ‘Tools’ button near the bottom of the left-hand navigation bar. Once the tools page loads, click on the ‘Export’ link underneath the ‘Tools’ button near the bottom of the left-hand nav.
4. Generate and save your blog export file. On the ‘Export’ page of your blog’s dashboard, make sure ‘All authors’ are selected in the ‘Restrict authors’ field, and click the ‘Download Export File’ button. On my Fedora 15 system, the file was automatically saved to the ‘Downloads’ folder in my home directory, with the filename ‘wordpress.2011-05-31.xml‘. The date in your export file’s filename will be the date you exported it.
5. Create a WordPress.com account or new WordPress blog in your existing account. If you don’t already have a WordPress.com account, you can create one at their signup page. Once you’ve created your new account, or if you already have one and you’re logged in, create a new blog by clicking on the ‘My Blogs’ navigation item in the upper left of the top navigation bar, and selecting the ‘Register a new blog’ option in the dropdown menu that appears. This will load up a form that will ask what subdomain you’d like to use for the blog and some other questions. Once you submit the form, your new blog will be created.
6. Load your new blog’s dashboard. Visit the dashboard for your new blog at WordPress.com by selecting ‘Dashboard’ from your new blog’s dropdown menu under the ‘My Blogs’ item in the upper left navigation bar. For example, my blog’s dashboard is at My Blogs > Duffy Fedora > Dashboard in the menu tree.
7. Import your Fedora Blog data into your new blog. On your new blog’s dashboard, click on the ‘Tools’ button near the bottom of the left-hand navigation bar. Once the tools page loads, click on the ‘Import’ link underneath the ‘Tools’ button in the left-hand nav. On the import page, click on the ‘WordPress’ link since you’re importing WordPress data, and finally on the page that follows, click ‘Browse’ and select your wordpress.2011-05-31.xml (the date in your filename may be different) file from your Downloads directory. Click the ‘Upload file and import’ button. You’ll be asked which person to map the authors in your file to. For example, on Fedora blogs my username is duffy, but on WordPress.com my username is mairin. WordPress will probably guess correctly for you, especially if your blog is brand new, but double-check just to make sure, and change the username in your account that your Fedora username maps to if you’d like. If you uploaded any files or photos to your Fedora blog, you may be able to import them into your new blog – turn on the ‘Download and import file attachments’ option if you’d like to try. Finally, click ‘Submit’ to start the import process.
8. Change your Planet Fedora feed. If you’d like to change your blog’s Planet Fedora feed, simply ssh (ssh your-fedora-username@fedorapeople.org) into the Fedora People server and edit the .planet file in your home directory, providing the new RSS url for your WordPress blog. It’ll be http://your-new-blogs-name.wordpress.com/feed.

At this point, WordPress should be actively importing your Fedora blogs content into your new account. WordPress will send you an email when the import operation is complete, and you’ll be all migrated from Fedora blogs and running on a newer version of WordPress as well!

The Burden of files

Okay, there’s a lot of problems:

• Backing up your files is a pain in the butt.
• Every time you upgrade your system, either in-place or a fresh install, it is a royal hassle to restore your files.
• That file looks great on your laptop, but how do you show it to a colleague not sitting next to you easily? Ughh.
• You upload files to a random directory on some web server you have some space on, quickly to show an idea to someone. Fast-forward some time, and you’ve got disorganized, poorly-named files scattered across multiple shell / other accounts all over the web, and you’re not sure what you have a copy of where, or which ones are being referred to from other places, so you’re terrified to delete any of them.
• Well, crap. You’ve made a mistake. You can’t go back, can you? No version control…

I think we all know these problems pretty well. I’ve built a solution using Fedora and Sparkleshare – completely free and open source software – that over the past week has addressed all of these issues and has substantially improved the quality of my computing life. It backs my work files up to an internal corporate server and it backs my Fedora files up to a Fedora-maintained public server. I’m planning to configure it to back up some personal files to my Dreamhost account and some to my NAS at home.

What? What are you talking about?

Here’s how it works: I have a ‘Sparkleshare’ folder in my home directory. Under that, I have a couple of subfolders:

• workstuff
• design-team (this is for Fedora stuff)

When I start a project, say it’s for work, then I create a new subfolder under the appropriate directory. So I’m starting a new project, let’s say it’s a logo design for project X. I have the following directory tree:

~/SparkleShare/workstuff/logos/

I open up Inkscape, and start working on the logo. I work on it for a while. Now I’ve got a draft I’d like to save and show to a colleague. From within Inkscape, I navigate to the SparkleShare > workstuff > logos folder and save the logo there. Then I can go to my internal server, and automagically, the logo file I just saved is at http://hostname/workstuff/logos/mylogo.svg. I can quickly copy/paste that URL from my browser and send it via IRC or email to my colleague.

No uploading, no fumbling to find a server that has space in an appropriate location, no waiting for the upload to happen, no coming up with some lame variation of ‘temp’, ‘tmp’, ‘foobar’, ‘blah’ to make a fresh folder to upload it to. Nope. It’s just there.

Here’s how to set this up for yourself.

Setup Walkthrough

Ingredients

You will need:

• A desktop or laptop computer with Fedora 14 or Fedora 15 installed. You’ll be needing root access.
• A remote server you’re going to use as your main git repository. This can be a server you administer yourself, or it can be a shell account with lots of space on a hosting provider like Dreamhost. It could even be a NAS if you can install git on it like you can on mine.
• An ssh key, preferably with a passphrase. I am assuming you already have your SSH key configured to enable you access to the remote server you’re intending to set your main git repo on. If not, the following resources below might be helpful:
  • What is an SSH key and why do I need one? (Documentation from the Fedora project.)
  • How to create an SSH key (Documentation from the Fedora project.)
• Files. Lovely little (or big) files.

Other assumptions:

• I’m assuming you’re using GNOME. Sparkleshare does work on KDE or XFCE or LXDE. What you lose by not using GNOME is the nautilus right-click extension that lets you – from gitorious or github repos – check out older versions of a document or grab a web link to the document. Not a huge deal.

Step 1: Prepare your local system

We’re going to install Sparkleshare first.

1. Open up a terminal.
2. Go to the yum repositories directory:

   cd /etc/yum.repos.d

3. As root, download Alex Hudson’s Sparkleshare Fedora people repo config:

    sudo curl -O http://repos.fedorapeople.org/repos/alexh/sparkleshare/fedora-sparkleshare.repo

4. Install sparkleshare and openssh-askpass:

   sudo yum install -y sparkleshare openssh-askpass

5. Remove nautilus-python (I don’t know why, but if you have this installed and install Sparkleshare, Nautilus will segfault on startup. If you remove it, though, everything works fine.)

   sudo yum remove -y nautilus-python

You now have Sparkleshare installed.

Step 2: Set up your main git repo

First you have to figure out where you want your main git repo to be. It needs to be in an account that your desktop/laptop can connect to. I set mine up in a remote home directory I own. Here’s how to do it:

1. We’re going to create the empty new git repo. In your remote home directory, type

   git init --bare repo.git

   . (If this command doesn’t seem to work and you have permissions to do so, try installing openssh-server and updating git.)

2. Now we’re going to make a dummy clone of the repo to add an initial file and branch. To make things more interesting, we’re going to do this in your public_html directory, but you can do it anywhere you’d like in your home directory:
   • Go into your public_html directory.

     cd ~/public_html

   • Clone it! Type

     git clone repo.git

   • Go into your new clone with

     cd repo

   • Now make a new dummy file,

     echo 'Fedora 15 rocks!' >> test.txt

   • Now commit it.

     git add test.txt; git commit test.txt -m 'initial commit2'

   • Push it, making your initial branch.

     git push origin master

Step 3: Hook your local system up to your repo

Okay, now we’re going to get your local system hooked up to the repo you just created on your remote system.
On your local laptop/desktop:

1. Turn Sparkleshare on. Click on its icon in your Applications menu, or run it from the terminal:

   sparkleshare start

2. Right-click on the Sparkleshare icon in your system tray, and select “Add Remote Folder…”
3. Where Sparkleshare asks you: “Where is your remote folder?” select “On my own server.” In the field after “On my own server, replace my fake credentials here with your own, and don’t forget the ‘.git’ on the end.

   user@hellokitty.ponies.com

4. Where Sparkleshare asks you for the “Folder name”, fill in something like this, replacing my directory structure with your own on the remote server:

   /home/user/repo.git

5. Sparkleshare should say something about ‘coffee o’clock’ and it should start pulling the remote files down.
6. Look in your Sparkleshare folder for the repo you just connected. Are the files from the server there?
7. Now we’re going to make sure it’s set up right. Create a text file in your new Sparkleshare repo directory (will be somewhere like ‘/home/user/Sparkleshare/repo’).

Okay, that should have pushed up to the server, no issues. Make sure it did; On your remote system where git is:

1. Go into your remote clone.

   cd ~/public_html/repo

2. Pull down the changes!

   git pull

3. Make sure the changes worked. You can either visit the web side of your clone at (replace with the relevant hostname and username) http://hellokitty.ponies.com/~user/repo or you can just cat it, making sure our new panda message is present:

   cat test.txt

All right, hopefully that wasn’t an issue either and your remote clone was able to pick up the panda PSA you pushed from your local laptop/desktop. Now we’re going to throw Sparkleshare into the mix.
On your local laptop/desktop where Sparkleshare is installed:

1. Restart Sparkleshare. You can click on the icon or

   sparkleshare start

2. Go to the Sparkleshare repo directory.

   cd ~/SparkleShare/repo

3. Make a new test file. In honor of towel day today:

   echo '42' >> theanswer.txt

Let’s see if it worked!!!!! On your remote system:

1. Go into the clone:

   cd ~/public_html/repo

2. Pull it down!

   git pull

Did it work??? It worked for me!!

Step 4: Set up automagical web mirroring of your repo’s content

Okay, so I did a sneaky thing. Our remote repo, in the examples above, has been configured in your remote public_html directory on the same system your remote git repo is. Now, you could follow these directions on a third remote system if you’d like; no problem. Just make sure you’ve got your public SSH key configured on that third system and that you have access to write to a web-readable directory. These instructions should not be difficult to modify for that case; simply git clone your repo in a web-readable directory.

We are now going to hook this all up so that when you save a file on your local laptop/desktop, and SparkleShare checks it in, the web-readable clone of it all also automagically pulls down your change and makes the file available in a web browser. Woo!

On your remote system:

1. Get into the hooks directory where your main (not clone) git repo is (don’t forget the .git!):

   cd ~/git.repo/hooks

2. We’re gonna set up a hook so whenever you push a file to the repo, it tells the web clone to pull. Create a file called ‘post-receive’ in ~/git.repo/hooks with the following in it, replacing ‘user’ with your own username on the remote system:

   #!/bin/sh
   
   while read oldrev newrev refname
   do
   true
   done
   cd /home/user/public_html/repo
   GIT_DIR=/home/user/public_html/repo/.git git pull
   

Okay, let’s see if it worked.
On your local laptop/desktop where Sparkleshare is installed:

1. Make sure Sparkleshare is running. If it’s not, start it.

   sparkleshare start

2. Go into the right directory and make another test file.

   cd ~/SparkleShare/repo; echo 'Fedora 15' >> latestfedora.txt

Okay, moment of truth. Is your new test file in your web directory? Either visit (replacing the username and hostname of course) http://hellokitty.ponies.com/~user/repo and look for a file named latestfedora.txt (if it’s there, it worked!) or on the remote system:

1. Go into the web-readable repo clone:

   cd ~/public_html/repo

2. Look for the file.

   ls

It worked!!

What do you think?

So, what do you think? Pretty awesome, right? Goodbye, dropbox – a worthless solution when your corporate IT policy rightly frowns upon copying internal documents to third-party public servers. You can create as many repos like this as you like. You can host them on a remote server you have shell access to, as this tutorial assumed, or you can set it up on Gitorious (I recommend this one since it’s backed by free & open source sw) or Github. Or a Fedora Hosted repo if you’ve got one. Each repo will have a folder under your ‘SparkleShare’ folder in your home directory, and anything in that directory is basically remotely backed up, instantly, as soon as you save files in those directories (and given that Sparkleshare is running.)

We’re currently experimenting with using this setup for the Fedora Design team to hopefully make it easier for folks to access our files and contribute.

Some things you might want to consider with this setup

• Set Sparkleshare to always run when your machine is booted. For GNOMEies:

  cp /usr/share/applications/sparkleshare.desktop ~/.config/autostart

• Write down the remote git URLs of all of the remote repos your stuff is backed up to and keep it in a safe place. If disaster strikes and a panda mistakes your laptop for bamboo, it will make it that much easier to recover.

Major kudos

• Hylke Bons and the rest of the Sparkleshare community for making such an awesome, life-changing tool.
• Alex Hudson for creating and maintaining the Fedora people repos Sparkleshare repository.
• Ray Strode, Kevin Fenzi, and Ricky Zhou for fielding my crazy git questions. Ray wins the prize for figuring out how to get past git complaining about a ‘sideband demultiplexer’.

Yesterday with some help from smooge and nb, I set up a Danbooru-style image board to test out, and I am hoping that Fedora artists and designers might play with it and see if it’d be a useful resource. It’s an application called Shimmie.

What is an imageboard? It’s a bulletin board or forum type of website that focuses much more heavily on images rather than text. You can read more about them in Wikipedia’s article. Traditionally they are used for ‘found’ images, and I don’t know if they are used much by folks who are generating original artwork, but it seems as if they would be a useful tool for collaborative image production, as they would keep discussion focused on visuals.

Anyway, if you are so artistically inclined, please feel free to try it out. It is a test server and it is not backed up, so make sure you keep local copies of your drawings or also copy them to your fedorapeople.org account.

http://publictest04.fedoraproject.org/artboard/

Fedora 16: Verne

I think maybe this imageboard it might be a cool opportunity to start sketching, sharing, and collaborating some Jules Verne and/or steampunk artwork ideas for Fedora 16 Verne, don’t you? So come on and let’s come up with something great together!

string for a kite by woodleywonderworks, used under a CC-BY license.

Some ideas to help get you started

Jules Verne was a novelist and according the Wikipedia, a pioneer of science fiction stories. Some of his most famous works include:

• Twenty Thousand Leagues under the Sea – A mysterious sea monster wreaks havoc on boat traffic and a navy crew attempts to fight it, and are lead on an adventure through the seas on the submarine Nautilus with Captain Nemo.
• Around the World in Eighty Days – Two men attempt to journey around the world in eighty days in order to win a bet, which they try to accomplish via a variety of vehicular means including an airship/hot air balloon, yacht, elephant, steamship, and train.
• A Journey to the Centre of the Earth – A professor and his nephew descend into a volcano in Iceland to reach the center of the earth, encountering mysterious and prehistoric creatures along the way.
• The Mysterious Island – Volcanoes, rescue missions, hurricanes, and secret islands are all elements of this story that follows a group of United States Civil War era castaways who escape in a hot air balloon to an island.
• From the Earth to the Moon – United States Civil War vets plan a journey to the moon by firing a capsule from a cannon at it.

Himmelskibet, Copenhagen by J.J. Hall, used under a CC-BY license.

Another idea that I just want to put out there… the Back to the Future movie trilogy, Jules Verne is Doc Brown’s hero, and eventually names his TOTALLY AWESOME FLYING STEAMPUNK TIME TRAVELLING TRAIN travelling sons ‘Jules’ and ‘Verne.’ Just saying. Flying steampunk time train. Just…. gently placing it out there and backing away slowly.

Um, so what do I do?

Here’s some steps you may wish to take to help us get an awesome suite of artwork put together for Fedora 16:

• Sign up for a Fedora artboard account, and provide feedback, advice, and ratings to folks’ artwork there.
• Search the web for theme-related Creative Commons-licensed inspirational images, and post them to the imageboard (but PLEASE, note the source URL in the ‘source’ field, and also provide the appropriate attribution information. Creative Commons NC and ND clauses are not acceptable for inclusion in Fedora, so please don’t use artwork with those in their license.)
• Sketch out some ideas, either via paper sketch + scan, or via MyPaint or the incredibly awesome new Gimp 2.7.2 development release, or of course Inkscape, and upload what you come up with to the Artboard.

I’m not an artist, how do I provide helpful critique on what the design team is working on so I can help too?

This is copied wholesale from an old blog post, but of course still applies.

Some folks understandably believe art and design are stuffs enshrouded in a mysterious haze of incense smoke without much logic or reason involved. I get it. I’ve been there too, and I think it’s easy to feel that way – discussions about art works sometimes get a bad reputation for being anywhere from fussy, to bizarre, to completely pointless.

You may find solace in the fact that there’s actually plenty of logical principles and elements and a vocabulary for them that can be use to discuss such works in a productive manner that doesn’t involve ‘invoking an embodiment of emotive symbolism’ or similar. I strongly recommend you explore some of this vocabulary, as not only will it help you more effectively communicate your critique but reading through a brief survey of basic design principles will probably even help you explain why you feel a particular way about an element of a work you’re critiquing. Some basic resources:

• Wikipedia: Design elements and principles
• Wikipedia: Composition
• Artwork Critique Form by Marvin Bartel

What makes for a good wallpaper design again?

The guidelines from the Fedora supplemental wallpaper submission guidelines are a pretty good guide here. Here are the compositional guidelines from that document, for example:

• Should strive for subtlety and poetry
• Avoid high frequency images – A soft focus is one way to achieve this
• As the name suggests, visually, it should settle into the “background” of the activity scene.
• Fewer details on left side allows for good readability for primary icons on the desktop. Keep in mind that many users have icons covering the entire desktop view.
• Do not compete for the user’s attention.

I gathered some CC-BY and CC-BY-SA examples which don’t necessarily meet all the guidelines but are good enough for inspiration purposes under a couple of Flickr galleries; you might get some ideas of the type of stuff that would be helpful at least for inspiration there:

• Fedora 16 Nautical Inspiration Board
• Fedora 16 Steampunk Inspiration Board

What are you waiting for?

So, let’s do it!

After the excitement and the fun that is the Red Hat Summit, I had some time this week to work with Jason on updating the design. Before I dive into the design process and the mockups, I think it’d be best to do a review of how cgroups work (or at least how I understand them to) so that the rest makes more sense. (And maybe I’ve got some totally incorrect assumptions about cgroups that have resulted in a flawed design, so hopefully my calling out the current understanding might make it easier for you to correct me ).

A designer’s understanding of cgroups via diagram

So cgroups, which are sometimes referred to as containers (I think because a similar Solaris feature, zones, is sometimes called containers) can be used to slice an entire operating system into buckets, similarly to how virtual machines slice up their host system into buckets, but without having to go so far as replicating an entire set of hardware.

So this diagram kind of shows how four of the system resources that cgroups can control – CPU, memory, network, and storage I/O – could be cut into slices that are then combined into two groups – the yellow and the purple one – which make up virtual OSes. Say I gave cgroup #1 (yellow) to Sally, and cgroup #2 (purple) to Joe. Whenever Sally starts a process, you could set it to only run on the CPUs that are members of cgroup #1 (via cpuset), at whatever priority level is set for those CPUs (via cpu). It’ll only be able to use as much memory as was allocated to cgroup #1, only be able to use as much network and I/O bandwidth as cgroup #1 is able to use. When Joe starts a process, because he’s part of cgroup #2, he won’t be using the same CPUs as Sally. He may have more or less memory, I/O, and network bandwidth allocated to him.

It’s kind of / sort of like Joe and Sally are using different computers, on the same operating system. Cool, right?

Cgroups don’t have to go that deep, though. You don’t need to slice across an entire system.

You can have a cgroup that *just* deals with controlling access to the CPU. Or *just* controls memory. Or maybe only deals with two of the four (CPU, Memory, Network, I/O) resources, or just three of the four.

You can have a cgroup that *just* deals with one resource (say CPU), and that group only deals with specific processes. Or users. Or a combination thereof. (More later on that.)

Depending on the resource you’re looking to control and the cgroups module you’re using, you can configure access to that resource in different ways. I believe one of the more common ways of controlling CPU usage via cgroups is to assign ‘shares’ for various groups’ usage of the CPU (using the ‘cpu’ module.) I’m not sure what scale/units these shares are on, but they are relative to each other, so if I give group #1 a weight a 1024, and group #3 a weight of 2048, then group #3 will get scheduled for CPU time twice as much as group #1 will.

I don’t think this share system is particularly intuitive, which is still an open problem in the current draft of the UI design.

Other resources and modules let you control access in different ways. For example, the memory module lets you configure an upper bound of memory usage, I believe via providing the maximum number of bytes of memory that could be used by members of the group.

You can create and apply cgroups to processes and users on-the-fly or on a longer-term / persistent basis. Say some process is running amok and is starving other processes on your system… you can change the process’ cgroup membership on-the-fly to provide it a more limited set of system resources so that other processes on the system can run. However, this change would be temporal and may be based, for example, on a specific pid number that won’t apply if the process is restarted or the system is rebooted. If you’d like more persistent cgroup membership, you can create a set of rules (cgrules.conf). A neat simple thing you could do with cgroup rules, for example, is something mentioned by Linda Wang in her Red Hat Summit talk on cgroups; you could arrange your cgroups rules such that the sshd always gets a dedicated chunk of CPU time so that if a process runs amok on a server system, you still might be able to ssh in remotely to diagnose the problem.

It’s via these rules that you can set up persistent groups on the system. It would be kind of a pain to have to set them up every time a system is rebooted, especially the more processes and users you’re managing, and the more groups you need to create in order to manage them. You can use multiple cgroups modules (for example, cpu, cpuset, mem, net) within a single cgroup, and then write rules to place processes run by particular users and/or user groups into the cgroup, or write rules to place processes matching particular attributes into the group.

Above is a diagram demonstrating a cgroup that restricts only CPU usage for processes matching firefox-*, npviewer.bin run by users that are in the ‘guest’ group or whose usernames are ‘student1′ or ‘student2′. Kind of putting it all together, showing a single group and its resource allocation, and its associations with particular users and processes.

Who would use a UI for this, and why?

Tthe UI design mostly focuses on setting up persistent rules, and doesn’t really allow for on-the-fly cgroups rearrangement of currently-running processes and currently-logged in users. The thinking behind this is that there might be a couple of main reasons you’d be using a UI for cgroups:

• Proactive: Initial system resource allocation planning
• Reactive: In response to a complaint – ‘My processes are getting capped,’ or ‘Such-and-such process isn’t running right.’

Thinking about the way my previous experience with system administrators has typically gone, there’s sadly not usually a lot of time for proactive planning and organization – a majority of time tends to get spent on reacting to client concerns. If someone is calling you up on the phone to tell you that a process they are relying on has gone awry, it seems the most effective way to get them to stop calling you would be to change the rules to make a more persistent change to help them, rather than to just apply a change on the fly and wait for their next phone call. So I think you’d probably prefer to change rules in reaction to a client complaint, not just do an on-the-fly change (although you could.) When you’re being proactive and initially setting up a system, I think you’d not want to do that on-the-fly at all, because you’d have to keep reapplying. It’d be better to craft a set of rules to persist on the system.

So it seems like these two main use case types – proactive resource allocation, and reactive allocation adjustments based on client feedback – are both best served by focusing on rules, so that’s why the UI design only focuses on those.

Maybe there is a case for doing the on-the-fly stuff though. It does make for some pretty awesome demos, though, like the one Bob Kozdemba gave at the Red Hat Summit last Friday, moving multiple copies of a graphics rendering tool between cgroups and vms and changing their configuration on the fly so you could visually see the affect of resource caps on the processes.) You could also use the on-the-fly configuration changes to test out a theory about how you should set the rules.

So, specifically, what kinds of problems could we imagine a user looking to solve with this interface? Our thoughts were that most likely a system administrator would find it most useful:

Under the ‘Proactive’ Category:

• I have a system running a business-critical app that sadly has a memory leak, and I want to make sure that app doesn’t screw up the other apps running on the system. I’d like to put a cap on its memory usage so when it goes down it doesn’t take the rest of the system down with it.
• I have a thin-client lab meant for the use of students in the science department, but students from other departments are allowed access via guest accounts. I’d like to make sure the guest accounts don’t block any of the science department students’ work on the server.
• I’m an administrator at an ISP and we provide virtual machines to end users in different pricing tiers. I’d like to enforce the limits set by our pricing tiers so that customers’ VMs aren’t getting more power than they are paying for and aren’t starving customers that are paying for more power.

Under the ‘Reactive’ Category:

• A student from the science department has called helpdesk to complain that his simulations don’t have very much oomph and are taking far too long to run. I need to figure out what system resource policy might apply to this user, and make modifications to his policy as needed to help him out if possible. (For example, perhaps he was previously outside of the science department and just transferred in, so he’s still running in the guest group.)
• Uh-oh, something’s gone wrong. A business critical process keeps getting OOM’ed! I need to figure out what resource allocation policy applies to it to see if there a rules that are causing the issue / that could be adjusted to get the app running consistently again.
• Our bi-weekly payroll processing application is still going full-steam ahead but it’s Monday morning, the business day is starting, and that server needs to be used for other things. Whoops, that’s never happened before, it usually finishes on Sunday. I need to see what policy applies to it, and modify our rules so that the payroll process tones things down a bit if it hasn’t finished over the weekend.

The mockups

So after a lot of sketching, crossing out, sketching, crossing out, and thinking about the above types of use cases, we thought to break up the main window in this way:

• A users tab: For when you have a specific user/group in mind you’d like to limit, or if you’ve got a specific user on the phone who you’re trying to troubleshoot with;
• A processes tab: For when you have a specific process in mind you’d like to limit, or if you’ve got someone on the phone upset about a particular process you need to help debug;
• A containers tab: For when you need to initially create your cgroups, or if you’d like to tweak the configuration of a particular group, or if you’d like to see how the processes within the group are performing.

So here’s what they look like:

The users tab

The processes tab

The containers tab

Some issues / further work

Here’s a bit of a braindump of where these need more work:

1. So I mentioned in one of the example use cases a payroll application, that could run full steam during the weekend but had to be dialed back during the work week. Well – this UI design doesn’t account for scheduling in the rules, yet.
2. There’s no mockups for the various dialogs needed for adding and modifying rules.
3. It would be cool to do a mockup showing how this might integrate into the GNOME system monitor – maybe an additional filter on it?
4. It would also be cool to have some kind of integration with the user accounts dialog. Maybe it’d show the policy that applied to a user and let you modify it from that dialog?
5. Right now in the containers tab, we had the idea to list the containers by the resource they are managing – so groups involving cpu, cpuset, cpuacct for example would all be listed under a ‘CPU’ category. However, Jason had an idea about showing logical cgroups that span resource types – e.g., you might have a cgroup tuned for DB usage with different settings for CPU in combination with memory & I/O.
6. The users and processes tab doesn’t really let you monitor resource usage per user / per process. Is that needed? Not sure.
7. Units – shares vs upper limits vs… the actual numbers you’re configuring for each rule need to be fleshed out. If cpu / cpuset / cpuacct for example can be used in conjunction, how would that be shown in the UI?
8. What about a mechanism to compare effective resource allocation vs actual resource usage? So you could see, ‘hey, this process is starved, maybe we should consider upping it,’ or ‘hey, this user isn’t really coming anywhere near their limits, should we dial them down?’ An earlier draft of the mockups showed graphs of each for comparison.
9. (Edit: idea from Bill Nottingham) Support multiple systems in one UI over the network

The wiki page for this design (including Inkscape SVG sources) is here:
http://fedoraproject.org/wiki/Design/CGroupsUI

Feedback

Is this nuts? Does it make sense? Is this the wrong approach? Do you use cgroups? Would this be a useful tool, or does it suck?

I hope you’ll let us know.

Lunchtime!

More booth shots….I think this guy must be a Mac fan:

Robin and Ruth.

Robin was the hero of our booth, he helped us out a ton:

Tux made many friends:

There was a lot of interest in our flyers and CDs!

A film crew came by to check out our photo booth system, written by Luke Macken and designed by design team ninja Emily Dirsh:

I also hear Tux visited with IBM’s Watson super computer. I hear Ruth has video

We’ve remodeled our booth after some ethnographic research on user patterns yesterday.

Penguin Prep

Lots more photos here, I’ll be updating as the flaky network connection allows so keep checking back.