The most important Flock Talk

I was just voting on FLOCK talks and happened upon this talk proposal:

What does Red Hat Want?

It’s no secret that many Fedora participants work for Red Hat. Or that Red Hat provides funding for the Fedora Infrastructure. There have been many conspiracy theories over the years centering on what, exactly, does Red Hat want out of Fedora in return. This talk, by the Red Hat VP who runs the RHEL engineering team, proposes to address that eternal question. What does Red Hat want? Join Denise Dumas to learn what Red Hat is working on next and how we would like to work with the Fedora community

In my time working for Red Hat on Fedora I often found that the Fedora Community was operating in a vacuum.  We wanted to run a Linux Distribution that we had a stake in and a chance to modify to our needs.  We also knew that Red Hat invested a considerable amount of money into Fedora to support our being able to do that.  But what we were in the dark about was what Red Hat expected to get out of this partnership and what they wanted us to do to justify their continued investment.  Although over time we did get our hands dirty maintaining more of the packages that made up the distribution, in a lot of ways we never graduated beyond mricon’s 2004 tongue-in-cheek posting about Red Hat’s relationship to its community (and its own internal divisions at the time).

In the last few years, Red Hat’s portfolio of products and future directions have greatly expanded.  No longer just a producer of a Linux distribution, Red Hat is pursuing revenue sources in application middleware, both IaaS and PaaS pieces of the cloud, and containers.  They also have engineers working on a multitude of open source solutions that enhance these basic products, adding flesh to the framework they set up.  But where does the Fedora Community fit into this expanded roster of technologies?  The Fedora Product has been very focused on “A Linux Distro” for a number of years but the Fedora Community is very broad and multi-talented.  I’m hoping that Denise’s talk will provide an entrypoint for Fedora Contributors to start talking about what new directions they can take the Project in that would align with Red Hat’s needs.  There’s a number of difficulties to work out (for instance, how does Fedora keep its identity while at the same time doing more work on these things that have traditionally been “Upstream Projects”) but we can’t even begin to solve those problems until we understand where our partner in this endeavour wants to go.

Flock Ansible Talk

Hey Fedorans, I’m trying to come up with an Ansible Talk Proposal for FLOCK in Rochester. What would you like to hear about?

Some ideas:

* An intro to using ansible
* An intro to ansible-playbook
* Managing docker containers via ansible
* Using Ansible to do X ( help me choose a value for X 😉
* How to write your own ansible module
* How does ansible transform a playbook task into a python script on the remote system

Let me know what you’re interested in 🙂

Try my Keyboard! activity at FUDCon Blacksburg

I’ve just added a new activity to the FUDCon Blacksburg page, a Try my keyboard! event. This is for people who realize that they spend hours and hours of their day typing into a keyboard, clicking with their mouse, drawing with their graphics tablet and… they love it! If you have a favorite keyboard, mouse, trackball, etc that you would like to give other people the chance to try out for an hour or so, consider bringing it to FUDCon Blacksburg. We’ll organize a space for people to get some hands on feel for the hardware you bring, let you talk about what makes it special, and let you interact with other people as crazy about the way their computer keyboard/trackball/input device feels as you do!

If you are going to be bringing some hardware for people to touch to the event, consider adding it to the activity’s page so that I know it won’t just be me and a couple keyboards in there 😉


Dennis, Jared, and I flew to FUDCon this week. We all encountered delays in our flights but luckily, we all made it in the end.

I’ve already learned something a bit surprising in its magnitude but that made sense after a little thought. Jayme Ayres mentioned that the language barrier is more of an issue when using email then when speaking. When speaking to each other, there is feedback (body language, immediate questions, etc) that make misunderstandings easier to resolve. When using email, there is a lot of miscommunication that can’t be ironed out in the same way because there is no body language and because the communication lacks… the participation of both parties.

In a face-to-face conversation where the speakers are not fluent in each other’s language, both parties need to help express one person’s idea… starting with a phrase in English and in Spanish/Portuguese and trying to create an English phrase that more accurately describes what the person means. What generally seems to happen in email is one person writes what they mean to communicate as best they can. Then the second participant interprets it and assumes that their interpretation is correct. This leads to problems as often the interpretation was faulty in small details and sometimes in the larger picture as well. Jayme went on to say that the fear of misunderstanding is high enough that at least some people do not write an email expressing their postions in the first place.

Figuring out how to change this is hard but seems necessary. Jared Smith had a few ideas such as

  • encouraging people to send messages that include what they want to say in their native language as well as their translation of it.
  • having people who can speak multiple languages helping to clarify when messages like this come across the wire.
  • having a packager language sig where people can go for help translating things they want to say to each other.

I think a deeper, culture change might be needed as well. Using Active listening strategies when responding to email could help us to communicate in a more welcoming and more comprehensible manner when we’re trying to deal with language barriers (as well as simply in some of the highly charged emotional battles that seem to spring up in Fedora from time to time.)

Distributing Content

One of the really interesting things that I heard at FUDCon was loupgaroublond’s thoughts on distributing content.  Content has been a bit of a hot topic for fedora recently.  In the past month I’ve seen mailing list and IRC discussions on:

  • Whether rpm packages of the books on Project Gutenberg would be good for Fedora
  • How to decide whether someone’s random pictures of London deserves to be packaged in an rpm that people can download from Fedora as wallpapers
  • How to best manage package (or not rpm package) the documentation that the Fedora Docs project produces given that translations and which Fedora Release a document is for can cause an explosion of documents.

These are all attempts to manage content using rpm, software which was originally meant for packaging software.  There are several advantages to using the package manager:

  • It lets the system administrator easily see that certain packages of content are installed on the system via the tool that they already know.
  • Having it managed this way means that individual account holders don’t all have to download separate copies.  You canhave a single copy of the files on the computer.

However, there’s also many disadvantages including:

  • How do we avoid conflicts in package names?  This is especially prevelant in content like “london-pictures”.
  • How do we decide where to break up content?  Should my pictures of London and your pictures of London be forced into the same package or separate?  On the one extreme we will end up generating huge packages for users to download, on the other we explode the number of packages (and hence the meta-data associated with the repositories).
  • How do we provide people with the ability to search and browse the content?  If you compare deviantart, KDE Look, or flickr to the Fedora Package List you’ll see that the process of looking for content in the package list is definitely suboptimal.

What loupgaroublond is proposing as a GSoC project is to make an alternate way of hosting, delivering, and managing content that does not involve the packaging formats that we use for software. In the comments to loupgaroublond’s post, Kevin Kofler links to the Open Collaboration Services API that’s being used by  This looks like a good place to start for the delivery portion of the equation.  Since opendesktop drives,, and others, they probably have some of the hosting equation worked out as well.  (Although I have a feeling that we could bring a lot to the table wrt managing mirror networks of the content via mirrormanager and other things we’ve developed purely for hosting the software that makes up Fedora).

However, that still leaves us needing to figure out how to manage the content once it’s on the computer.  This consists of at least two parts:

  1. A standard for how to organize and find the content on the system.  This probably includes a set place in the filesystem for installing content systemwide and another spot for installing software in the user’s home directory.  It would also include metadata that could be associated with the software and some standard APIs for accessing the information.
  2. A method of tracking what things are installed on the system.  loupgaroublond hints about this when he talks about a “content database system”.  For software packages in Fedora, rpm keeps a database in /var/lib/rpm that tracks what software is installed, metadata about the software, and where on the filesystem it lives.  We’d need something similar for tracking content with the addition that it needs to merge with tracking information stored in the user’s home directory.

Figuring out answers to these problems would be a worthy summer project that would benefit a broad spectrum of projects.  Unix-like distributions, would gain a way to deliver a hoard of free content.  Content authors would find a larger audience for their work.  Programmers would be provided with a means of sharing content resources on the system with each other and an API to access the content locally and possibly remotely.  System administrators would be able to manage free content similarly to how they manage free software on their systems.  End users should gain access to content from a consistent interface rather than having to traverse the internet, searching a variety of different websites with different UIs for what they’re looking for.

Any takers?  Please contact loupgaroublond using one of his preferred contact methods.