Two months after the launch of Fedora 12, we spoke to Paul Frields, Fedora Project Leader at Red Hat, about how this release has been received by the community, and what is in store for the next. Though it started as a technical discussion on what Fedora 12 offers IT admins and developers, it graduated into a more serious conversation on the relationship between Fedora and Red Hat Enterprise Linux, and the distinction (if any) between commercial and community Linux.
What is the general sentiment amongst the team, two months after the launch of Fedora 12 — how has the community’s response been like, what are the hit features, and what are the ideas for further improvement that have come about?
Uptake of Fedora 12 has been very good overall. There have been a number of very visible improvements in free video drivers for ATI and Intel that make for a better experience out of the box. Those improvements allow users to make use of 3D effects on the desktop, as well as kernel mode setting for an attractive and smooth boot experience. The free Nouveau driver for NVIDIA cards has also greatly improved to allow kernel mode setting, and Fedora continues to contribute to moving that driver forward to support features like 3D.
A very visible set of features came with the fit-and-finish improvements in the user desktop. Menu cleanups, better icon spacing, a new notification engine, improved tooltips, consistent ordering of status icons, and a fresh and usable desktop background were just some of the improvements. These improvements result in a generally more pleasant user experience on the desktop, from which everyone benefits. An in-depth interview about those features is found here.
One of the “come from behind” hit features in Fedora 12 seems to be the Automatic Bug Reporting Tool (ABRT). It captures information when a program crashes, and helps the user report that bug, along with full debugging information, into the Bugzilla tracker that Fedora uses. Developers get a lot more helpful information about bugs and can figure out where they need to prioritize their attention. We used ABRT during the development of Fedora 12, and it was handy for fixing a number of bugs for which it would have been very difficult to discern the cause without ABRT.
For the IT admins reading this interview, could you explain what the virtualisation and networking improvements in Fedora 12 are?
One of the most prominent features is the tool set for working with virtual guests, outside the virtual environment itself. With libguestfs and guestfish, a sysadmin can make changes on a guest image without having to actually boot up that system. If that image is used as a “golden image” or baseline for many systems, the capabilities of these tools are extremely valuable. Good sysadmins are always looking for clever ways to avoid having to do things manually that can instead be automated. If the sysadmin doesn’t have to start up guest systems to make changes, but can script this work, common changes can be built into all sorts of clever automation, allowing sysadmins to better manage their time.
Another major improvement is memory management across multiple guests. In a lot of cases, virtualisation is used to host a large number of very similar guests. With Fedora 12, we’ve introduced a kernel shared memory feature that eliminates duplicate memory areas across guests, pointing instead to a single page in memory. So if you have any two virtual guest machines, each assigned, say, 512 megabytes of RAM, that load many of the same things into memory, the actual memory usage of each machine may be much lower than that 512 MB. Of course, that means that on the same host hardware, you can now fit more guests into the same amount of physical RAM. And this is managed without any special fiddling with configuration, again making life easier for the busy system administrator.
There are many other virtualisation improvements, and there’s an in-depth set of interviews about them here.
From a developer’s perspective, what are the most interesting features in Fedora 12?
Linux, and Fedora in specific, has always been the best-engineered and featureful platform for development, out of the box. With support for dozens of complete programming language, any programmer can scratch an itch using Fedora. We’ve offered a number of graphical, integrated development environments (IDEs) in Fedora for some time, including the very popular Eclipse IDE, with support for many languages and also plugin development.
But now we’ve also added a refresh of the SystemTap profiling capability, which allows developers to trace information about code and kernel execution without having to instrument, recompile, reinstall, and reboot their systems. SystemTap 1.0 now includes support for updated GCC debuginfo, kernel tracepoints, static probe markers, and tools and development extensions for a number of advanced functions. And furthermore, SystemTap 1.0 has been integrated with the Eclipse IDE so that programmers can launch SystemTap scripts on their C/C++ projects from within Eclipse, and link SystemTap data with Eclipse graphics.
With Fedora 12, we also added support for the latest NetBeans 6.7.1 IDE, which includes Maven support for creation of plugins and web services, as well as other features. (More information is available here.)
Which of these improvements in Fedora 12 do you think will be significant value-adds to future versions of Red Hat Enterprise Linux?
Because Fedora operates as the upstream for Red Hat Enterprise Linux, you can expect to see a number of these features in future releases. Red Hat Enterprise Linux is by far the preferred open source platform for businesses that want to make smart, future-proof investments in IT on shrinking budgets. So the virtualisation, development, and user-facing features of Fedora 12 — better performance, more extensive and efficient support of hardware, and improved ease of use — are all indicators of substantial advancements and value in the next release of Red Hat Enterprise Linux.
What next? What are the key features the team plans to work on for the next release? That is, on what lines should contributors start thinking about now?
Besides the usual improvements that come with the newest releases of popular desktop environments, we already have many features on the slate for Fedora 13, which is due for release in May 2010. These features include a parallel-installable Python 3 software stack, language package plugins for the yum software management system, an improved user account tool for single-user systems and small deployments, colour management for displays and printers, and a truly minimal boot environment for installation or testing through the boot.fedoraproject.org site.
If you were asked to give one piece of solid, valuable advice to IT admins using Fedora, what would it be?
Get involved in the worldwide Fedora community. You can get instant access to helpful advice, tips, and knowledge through our mailing lists and forums. You can meet like-minded admins that are using Fedora to get a peek at next-generation open source technology. And you can leverage the collective experience of tens of thousands of Fedora users around the world. And most importantly, you do not have to be just a voiceless consumer of technology, as is the case with many proprietary systems. With very little effort, you can become part of the process of improving and shaping the direction of the technology leader in Linux distributions. It all starts by visiting our helpful page on interacting with the community.
If a team of developers caught you by surprise and asked, “We want to contribute to Fedora. What do you want us to work on right now?”, what would your answer be?
It would depend on what their developer skills are! If the developers worked primarily on web applications, either PHP or Python, I’d get them involved in our Websites team and on the rollout of our new Fedora Insight system.
I would point experienced C/C++ developers with a background in user applications to our Desktop team that works on core functionality at that level. On the other hand, if they were hardware hackers, I’d probably point them to the upstream kernel community and encourage them to use Fedora for their testing platform since we have a great track record for working with the upstream kernel community, and not hacking around them.
We also have teams that work on illustration and design, marketing, documentation, and infrastructure/system administration. To become a member you do not need to be specially “voted in”, or approved–to join, you simply create an account at join.fedoraproject.org and then jump in to help on one of the lists in your area of interest, as shown on the “communicating and getting help” page.
There are plenty of ways to get involved with Fedora — we believe in encouraging people to be self-starters, volunteers who look for ways to help, rather than being treated as employees and told where to work. It’s easy to find things that need doing, and people become contributors by simply finding something that interests them, telling people they’re going to work on it, and then doing it proactively, in collaboration with other Fedora Project members.
Assume an IT administrator who is not cost constrained. He is faced with a choice between RHEL and Fedora. Can you give us three reasons in favour of each choice? That is, three reasons why he could choose RHEL, and three reasons why he could opt for Fedora.
Can you explain the symbiosis between Fedora and RHEL? How does each contribute to the other?
I think these two questions are best answered together.
Fedora is not something recommended for use in long-term production environments. That’s not because it’s unstable, because it isn’t; and of course it has advanced, next-generation features.
Fedora might be unsuitable for many IT administrators because of its short lifecycle: the end of life for a Fedora release comes a month after the second following release. A month after Fedora 12 was released, Fedora 10 went to end of life and no longer receives security or errata updates. That lifetime is only about 13 months, and most administrators don’t want to roll over their production environments annually.
Red Hat Enterprise Linux, on the other hand, is supported by the world’s leading open source company for at least seven years after release. That means IT departments can be assured of a stable, reliable platform for rolling out their deployments, that respects their bottom line and planning cycle.
However, Fedora gives IT departments something valuable on top of their investment in Red Hat Enterprise Linux. Fedora represents a way to be involved in the future of the platform they already invest in, and Linux technologies that will shape the industry tomorrow. This is something no proprietary platform can offer.
So for instance, an administrator might have a closet full of Red Hat Enterprise Linux servers running virtualized guests and the software stacks of his or her choice, but on the desktop the administrator team might be using Fedora to plan for the next generation of production environments they’ll use a couple of years down the road.
This is how IT environments can maximize their investment in open source. Linux helps IT environments do more with less, saving time and money through virtualisation, higher performance, energy efficiency, and a number of other features. By taking that cost savings, and applying it to solving real, business-specific IT problems, any business can improve their bottom line.
This relationship between Fedora and Red Hat Enterprise Linux is the key to both Red Hat’s success and the success of Red Hat customers. And it’s equally applicable whether you have two system administrators and a rack of servers, or two hundred IT admins and a global, enterprise-class architecture.
What do you think is the key difference between commercial and community open source projects? When will this difference fade?
I think the Fedora Project has done quite a lot to break down the onus around what some people consider “commercial” open source projects. In Fedora, Red Hat is a contributor that puts resources and effort into specific areas of interest. In the same way, any volunteer can do the same thing.
Fedora in one sense is a gigantic, effective R&D laboratory for any person or group who wants to collaborate with others using open source methods, to produce results that can be used, modified, and redistributed freely by anyone. We have contributors outside Red Hat, for example, who work on projects such as a learning environment for children called Sugar, and a collection of electronic device design and analysis tools for use by engineers.
Red Hat’s particular interest lies in core pieces of the Fedora platform that are the upstream for its Red Hat Enterprise Linux product. So it works first in upstream communities like the kernel, X.org, and so on to originate new free software under the GPL. Then it also contributes to Fedora, to integrate that software in a form that is freely available for anyone. There are only a few people in Red Hat who are paid to work full-time on Fedora; most engineers who are producing software split their time in this fashion.
This is the exact same route that any unpaid volunteer can participate in Fedora. So the distinction between commercial and community has become a bit outdated in the case of the Fedora Project. Fedora is a great place to contribute to technologies that will be the most relevant around the world in the future.
How important is India, from the Fedora community perspective? That is, how good is the developer base, how involved are Indian developers, what have the key contributions of the Indian Fedora team been and what are they working on now and how can Indian developers be motivated to do more for the community?
Fedora places a high value on growing our community worldwide, including India. This heat map shows a distribution of Fedora mirror usage worldwide.
As you can see, India has a considerable concentration of Fedora systems and users, and the number of local mirrors carrying Fedora is steadily increasing in India. In January of this month, for example, another public mirror was added in Mumbai. We also have a number of very valuable members of the Fedora community working from India, including Susmit Shannigrahi who coordinates our FreeMedia project; Debarshi Ray who maintains a number of software packages in Fedora and also originates some desktop software himself; and Rahul Sundaram who has been a member of the Fedora Project since its earliest days and works on a number of areas including marketing and documentation.
One way Indian developers can be motivated to do more in the Fedora community is by meeting in real life. There are a growing number of free and open source software conferences happening in India, and we encourage developers to make the time to attend and spread Fedora, and also to meet and discuss areas where they would like to aid in the development of free software and specifically Fedora. The social bonds that develop at real-life conferences are indispensable in building strong community and collaboration.
Fedora employs a strategy of creating sustainable community through regional leadership, through contributors known as Ambassadors. We also have a specific list for use by users and contributors in India where developers can interact with each other and the Ambassadors. We have several key Ambassadors who coordinate regional work in India, and they are all members on that list, so we encourage developers to join it and get in touch with each other.