LWN.net Logo

Of rings and things

By Jake Edge
August 14, 2013

The idea of organizing a distribution into "rings" appears to be an idea that is resonating right now. Last week, we reported on some openSUSE discussions surrounding some of the problems the distribution is experiencing, along with possible solutions. One of those solutions involved separating openSUSE into cohesive chunks (i.e. the rings), each of which is built on the capabilities of the lower rings. As it turns out, Matthew Miller, Fedora's Cloud Architect, posted a similar idea to the fedora-devel mailing list in July. It would seem that Fedora and openSUSE are both experiencing many of the same problems—and perhaps coming to some of the same conclusions.

Miller not only posted his ideas to the mailing list, he also presented them at the recently concluded Flock conference for Fedora contributors. The slides, video, and transcript from that talk are all available for those interested. In essence, the mailing list post was a preview of what he presented.

After starting by outlining the obligatory good attributes of Fedora, Miller pointed out some of the same problem areas that SUSE VP of Engineering Ralf Flaxa noted in his openSUSE conference keynote: Fedora is not as widely used as it could be, including by users of RHEL, the distribution is not seen as particularly relevant (or exciting), and it isn't a good base for others to build upon. To solve those problems, Miller suggested the idea of breaking the distribution up into rings.

Miller starts by describing Ring 1 as "Fedora Core"—a name that predictably raised some hackles on the list. The original Core was determined based on who maintained the package. Those handled by Red Hat employees went into Core, while those maintained by volunteers went into "Extras". There wasn't any way for the community to participate in the development or maintenance of Core. In addition: "the quality standards for Fedora Extras, the collection of packages built around the core, were much, much higher. Upside-down!", he said. Those mistakes would not be repeated, he stressed.

So, Ring 1 contains the "base functionality and behavior that everyone can expect of any Fedora system". It is, in effect, the foundation for the higher levels. Underneath Ring 1 is Ring 0, which is "Just Enough Fedora". It would be based on the current @core, but would be slimmed down from there.

Ring 2 is less of a ring, really, and more of a collection of what Miller calls "environments and stacks". Environments are "where you run the code you care about", and he gave examples like desktop environments, as well as cloud and virtual machine images. Stacks are collections of tools used by other software, such as languages, database systems, web frameworks, and so on. Perhaps X and Wayland would be considered stacks in that model, he said.

The idea behind the rings is to give the Fedora special interest groups (SIGs) a place where their customizations fit into the Fedora picture. Each ring would have less restrictive policies as you move toward the higher levels, so changes to Ring 0 for a Spin (which is the end product of a SIG) would likely not be possible, and Ring 1 changes strongly discouraged (or disallowed), but Ring 2 would be more open.

Some of the kinds of policies that SIGs might want to override include packaging type (e.g. not RPM), changing software versions from lower rings, allowing some library bundling, and the lifecycle. So, potentially a SIG could create a Spin that had a longer life than the 13-month Fedora norm, for example, or that certain package versions (a language, say) would be supported longer than it is elsewhere in the Fedora ecosystem.

That "elsewhere" is what Miller calls the "Fedora Commons". It would contain the packages that are outside of the Core and the packages would be maintained in the same way that Fedora does today. In fact, any of the packages that aren't incorporated into Rings 0 or 1 would automatically become members of the Commons. These are the packages that SIGs could choose to maintain separately in order to differentiate their Spins from the rest of Fedora.

Miller's proposal is quite lengthy and detailed, the description here largely just hits the high points. There has been, unsurprisingly, quite a bit of discussion on the list and it can only be characterized as "mixed". That's not much of a surprise either—it's rare that a radical reshaping of anything is met with immediate near-universal acclaim (or condemnation for that matter). The transcript of Miller's talk indicates that people are certainly interested in the topic as does the mailing list thread.

It is, of course, just a proposal, and one that Miller makes clear is not set in stone (how could it be?) at all. It is an interesting rethinking of what a distribution is and how it might be structured. It is also completely different than what other Linux distributions are doing, which might make it fairly risky. Except that openSUSE may be headed in a similar direction.

Perhaps that's the most interesting piece: two distributions looking to grow their user and contributor bases are both considering fairly radical—but similar—changes to their structure. Where either distribution goes is anyone's guess at this point, but it will be worth keeping an eye on the discussions and, if any should materialize, plans. Stay tuned ...


(Log in to post comments)

JeOS

Posted Aug 15, 2013 16:22 UTC (Thu) by ayeomans (subscriber, #1848) [Link]

I've been surprised that the JeOS (Just Enough Operating System) approach - providing the minimum functionality to run under a VM - seems to have somewhat stagnated. [JeOS is mentioned in Matthew's slides within Ring 0.]

A while back I dabbled in looking at what packages would be required to run under all the common VM environments, cutting out the drivers and services that would not be needed. I didn't find any published work on what those VM environments actually supported. It seemed the only way to proceed was to run them up and check the configuration.

Or have I missed something?

JeOS

Posted Aug 15, 2013 18:44 UTC (Thu) by smoogen (subscriber, #97) [Link]

The problem is that JeOS seems to change for each person talked with. While some want kernel+minilibc+busybox, others want more and more functionality until you are back to @core - whatever package I don't really use.

JeOS

Posted Aug 16, 2013 15:46 UTC (Fri) by jwboyer (subscriber, #23296) [Link]

That's really by definition though. "Just Enough" is exactly "whatever you think is enough" or "the bare minimum, plus what you need to accomplish your task".

JeOS isn't about providing a small building block. It's about enabling users to create images that solve their problems.

JeOS

Posted Aug 16, 2013 0:31 UTC (Fri) by dberkholz (subscriber, #23346) [Link]

It's kind of cropping up again in the form of CoreOS.

JeOS

Posted Aug 17, 2013 20:49 UTC (Sat) by drag (subscriber, #31333) [Link]

It comes and goes.

Personally I find the network installs of either CentOS or Debian fulfill my 'Virtual OS' needs fantastically personally.

For work the packages provided by distributions are really quite worthless. When you are dealing with 30+ specific web-based applications with teams of hundreds of developers you'll find that not only you need to have very specific versions of X Y or Z software, but that you'll need very easy ways to roll back versions and such things in case you run into a problem. We end up needing a heavily massaged RPM-based solution that has it's rpmdb and such kept separate from the OS. It's really quite terrible.

JeOS

Posted Aug 19, 2013 16:29 UTC (Mon) by dag- (subscriber, #30207) [Link]

That's why most (enterprise) companies standardize and mandate that applications (home-made or bought-in) should work on their standard OSes. In some cases the standardized OSes are subdivided in the preferred OS(es) (e.g. RHEL6 or Windows Server 20XY) and other supported OSes (e.g. RHEL5, Solaris, ...).

That's also the reason why RHEL (and CentOS) are so popular, because that's more often than not considered the standard OS within larger environments.

Sure it means you won't have the latest PHP performance tweaks or the latest functionality from some library. But either you run moving targets (and every deployment is different) or you standardize.

I'd think this would be common practice by now, but too often we are confronted with some team that decided that the latest PHP, python or perl would be very convenient (to them) not considering the implications of such self-centered behavior.

Working in an environment (IT development) where everything seems possible, restricting yourself should be a natural reflex, even if just for the sake of simplicity downstream.

JeOS

Posted Aug 19, 2013 18:46 UTC (Mon) by raven667 (subscriber, #5198) [Link]

> I'd think this would be common practice by now, but too often we are confronted with some team that decided that the latest PHP, python or perl would be very convenient (to them) not considering the implications of such self-centered behavior.

I've had that argument and the response I received was that the servers and sysadmin staff existed to run the software that development made to solve business problems and so the sysadmin staff trying to dictate standards to the development staff was the tail wagging the dog.

JeOS

Posted Aug 19, 2013 22:07 UTC (Mon) by dag- (subscriber, #30207) [Link]

And that's when you end up with support nightmare and unique environments for each application :-) I know the battles though, but the larger the company, the more evident that there's a need for standardization.

As soon as we put the responsibility for security patch management, support and maintenance in their lap (or the overhead is billed to their department for deviating from standard support), it becomes an economic decision for the development team.

Usually it is Security Governance policies (regarding vendor support, security patch management and SLAs) that is backing us up on this as well.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds