covered the debate within
the Fedora project
Two weeks ago, LWN
over whether its ARM port should be designated one
of that distribution's "primary" architectures. That discussion has
progressed a little further, so an update may be warranted. But it may
also be worthwhile to address a related question: why is there resistance
to the concept of supporting ARM as a primary architecture in the first
place? And why might it make sense to promote the ARM architecture anyway?
One of the things that came out in the original discussion
is that the Fedora project did not have any idea of how to do that. Over
its entire history, the project has never before seriously considered
moving one of its secondary architectures to primary status. So there are
no procedures in place and no criteria by which a decision to promote an
architecture can be made. So, unsurprisingly, the project decided that it
needs to come up with a set of reasonable criteria. On April 2,
Matthew Garrett posted a
draft showing what those criteria might look like.
The rules would appear to make sense. The Fedora infrastructure and
release engineering teams need to have people who are able to represent any
new primary architecture. The project must be able to build packages on its
own servers. Anaconda, the Fedora installer, must work on the targeted
hardware. Maintainers of important packages must have access to the
supported hardware so they can fix problems. No binary blobs. And so on.
Also required is approval from various Fedora teams, each of which can
impose additional criteria if it sees the need. These rules are in an
early form and can be expected to evolve over time, but the early
responses on the mailing list suggest that most people are happy enough
with what has been set down.
That said, there are clearly some people who do not see the point of
supporting ARM as a primary architecture, and they have a number of reasons
for their reluctance. The ARM architecture is messy, for example. The x86
architecture does not have a single design authority, but processors made
by multiple vendors still resemble each other closely enough to create a
fairly tightly-knit processor family. ARM does have a central
design authority, but that authority leaves a lot of significant details up
to individual manufacturers, of which there are many. So ARM is not
a tightly-knit family; it is more like an extended group of hostile
ex-spouses and in-laws who have moved to different continents to get away
from each other.
The looseness of the ARM "platform" had led to a lot of innovation in the
design space; there is no end of interesting ARM system-on-chip designs
with all kinds of impressive integrated peripheral devices. But this
diversity, along with a distressing lack of hardware discoverability, makes
it impossible to create a single kernel that works on all (or even a
significant subset of) ARM processors. Distributors hate having to
maintain multiple kernels, and they hate having to put target-specific
hacks into installers. ARM currently forces both, despite the ongoing work
to consolidate kernel code and move hardware knowledge into the
bootloader-supplied device tree structure.
ARM is also, for many developers, a relatively obscure architecture lacking
the familiarity of x86. The fact that there are vastly more ARM systems
running Linux than x86 systems does not really change that perception; most
of us lack ARM-based development systems on our desks. Additionally, ARM
relatively slow. That is a problem for developers, who typically need to
keep an x86 system and a cross-compiling toolchain around to be able to get
through more than one edit-compile-test cycle in any given day. That
slowness is also an issue for distributors; it can delay security updates
and distribution releases, even for other architectures. And, while the
hardware is slow, product cycles are fast; by the time developers have
gotten a target working nicely, it may be obsolete and off the market.
Given all of these challenges, it is not surprising that some people would
rather not be bothered by an architecture like ARM. The x86 world provides
plenty of open, high-performing systems with wide support; why get
distracted with that messy architecture where, even if the distribution can
be made to work, the hardware is probably closed and won't allow it to be
The answer, of course, is that said messy architecture is already
performing much of our computing, and it will likely be doing more of it in
the future. Traditional PC-style systems are no longer the center of
attention; one assumes they will not go away entirely, but a lot of the
action is elsewhere. There is a whole new crowd of makers looking to do
interesting things with ARM-based designs; we are just beginning to see
what can be done with interesting mobile devices, and the bulk of those
devices are not, at this point, using x86 processors. Meanwhile, ARM has
its eyes on data center applications where, some think, its compactness and
power efficiency will make up for its lack of speed. The x86 architecture
will be with us for a long time - even Intel has proved unable to kill it
off in the past - but it is far from the only show in town.
It is also worth remembering that, for all its success, Linux is still a
minority player on x86 systems. But Linux is the dominant system on
ARM-based systems. The "year of the Linux desktop" may be an old and sad
joke, but the year of the Linux gadget looks to be happening for real -
Given that ARM is where much of the action is, it would make sense that a
Linux distribution - especially one that is supposed to be leading-edge and
forward-looking - would want to support ARM as well as possible. Solid
support for the architecture seems like a necessary precondition for any
sort of presence in the interesting computing devices of the near future.
Distributors like Ubuntu appear to have come to that conclusion; they have
built on Debian's longstanding ARM support to create a distribution that,
they hope, will be found in future devices. Without well-established ARM
support, Fedora - along with the distributions derived from it - has little
chance of competing in that area.
So one might well say that the questions being asked in the Fedora
community are wrong. Rather than asking "why should we support ARM when it
presents all of these difficulties?", it might make more sense to ask "how
can we address these difficulties to provide the best ARM-based
distribution possible?". The cynical among us might be tempted to say that
Red Hat, Fedora's sponsor and main contributor, faces a classic disruptive
technology problem. ARM is unlikely to displace x86 in the places where
Red Hat currently sells support, and revenues from any future ARM-based
"enterprise" distribution seem likely to be rather lower than those
obtained from x86-based distributions. So it would be understandable if
Red Hat were to show a lack of enthusiasm for the ARM architecture.
The cynical view is, at best, only partially right, though. Red Hat does
not advertise the resources it is putting into ARM distribution
development, but it clearly has a number of engineers on the task. Even as
a "secondary" architecture, Fedora's ARM distribution has been solid enough
to serve as the base for the ARM-based OLPC XO 1.75 laptop.
Without Red Hat's support, there wouldn't be a Fedora ARM distribution even
with secondary status. So it seems unlikely that Red Hat is the sticking
point here, even if its contributions to the kernel's ARM subtree (29
patches total from 3.0 to the present) show little enthusiasm. More likely
we're just seeing the usual noise as the wider community comes to terms
with what will be required to support this architecture properly.
In the end, the world would not be well served by a single processor
architecture; there is value in diversity. Similarly, an industry where
ARM-based systems are dominated by Android variants may not be the best
possible world. A lot of interesting things are happening in computing,
and many of them involve the ARM architecture; there is a lot of value in
having strong community-based distribution support for that architecture.
That is why Fedora will, in the end, almost certainly bother to support ARM
as a primary architecture despite the challenges it presents.
to post comments)