LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
DistributionsFedora wrestles with ARM as a primary architectureThere is no denying the rise in the popularity of the ARM architecture, but how exactly the Linux community responds to its popularity is a more complicated question. Case in point: right now, the Fedora project is engaged in a lengthy debate about the recent suggestion that ARM be promoted to the status of primary architecture (PA). The key points of disagreement are not the importance of ARM, but whether Fedora's existing ARM porting team needs to produce a release equivalent to the x86 releases before being declared a PA—and, if so, precisely what constitutes equivalence. Jaroslav Reznik proposed the promotion as a change for the Fedora 20 (F20) development cycle. In reply, Miloslav Trmač asked how many F19 packages are currently missing on the ARM platform, either because they fail to build or have been removed. He cited Fedora's guidelines for promoting a secondary architecture to PA status, which lists eleven criteria for promotion. Some of the criteria are technical requirements, such as the use of the Anaconda installer "where technically possible," while others deal more with the project infrastructure or developer-power, such as requiring all builds to occur on Fedora-maintained build servers and requiring "sufficient developer resources" to fix architecture-specific bugs." ARM holesIn the subsequent discussion thread, a number of packages were brought up that currently do not build, most notably the GNOME Shell desktop environment and the stack protector. Specifically, GNOME Shell does not work on ARM because there are not open source video drivers for the target hardware devices, and the LLVM-based software renderer is broken. Supporters of the promotion argued both that non-GNOME desktops are supported, and that binary video drivers are available for users that want GNOME Shell specifically. Strictly speaking, the PA promotion requirements state that requiring binary-only drivers is not allowed. But that leads to another question: whether providing support for GNOME Shell is required of all PAs. Matthew Garrett argued that the assumption has always been that all PAs "embody the same level of functionality, with the exception of fundamental differences between the architectures," down to the package level. But Peter Robinson took issue with Garrett's assumptions, noting that:
I don't necessarily agree
that while the gnome desktop is the default that it's an explicit
requirement. There's 4 million XOs shipping Fedora (both x86 and ARM)
that don't ship with gnome3 as well as no doubt millions of instances
of cloud images that don't have a requirement of a desktop yet we
still call them Fedora...
But the lack of GNOME Shell support has another dimension, which is the scarcity of developer-power for Fedora's ARM team. Elsewhere in the discussion, Garrett had also contended that LLVM support on ARM has been broken for months, but that no one has fixed it. Similarly, the stack protector has been broken for some length of time, and that impacts a security feature, which if anything makes it more important than any one desktop environment. But Jonathan Masters countered that the stack-protector issue was fixed within a day after it was raised; the team simply did not know about it before it came up in the promotion discussion. Developer time is not a simple quantity to be measured, though. As Adam Jackson weighed in on the topic of fixing LLVM, "fixing" software rendering is still a bit of a band-aid solution to the more difficult underlying issue that no one seems to be addressing:
If we really wanted to talk about graphics on arm, we'd be talking
about writing drivers for GPUs. You know, fixing actual problems,
instead of throwing our hands in the air and switching out the entire
UX because we can't be bothered to make the core OS any good.
There were still other practical objections raised to the PA promotion change, including the speed of builds, which Aleksandar Kurtakov estimated to be about ten times slower than on the x86 architectures. The speed issue has at least two negative effects; first, as Caolán McNamara observed, it changes build workflow from a "start today, get results later" model to "start today, get results tomorrow." Second, there may need to be changes made to the Fedora build servers themselves, as they currently have a hard-coded 24-hour time limit for each build. For large ARM packages, that may be insufficient. Speaking of Fedora hardware infrastructure, Till Maas questioned whether there will be test instances of ARM machines available for package maintainers, while others raised the same question about Fedora's QA team. I don't think it means what you think it meansNaturally, whenever the topic of ARM hardware comes up, it quickly becomes apparent that different parties have significantly different devices in mind. Bastien Nocera asked what the focus of ARM port is, specifically whether it was focused just on development boards like the BeagleBone and PandaBoard. While fun to play with, they have questionable value as a "primary" system. Adam Williamson pointed out that the vast array of ARM hardware on the market poses practical problems as well: what sort of images would Fedora actually be releasing? Potentially there would need to be separate builds for a range of different devices and System-on-Chip (SoC) boards, which would result in a very different "deliverable" than the unified x86 image. Also, he said, PA status would officially place the burden of testing all of the different ARM images on the already-busy QA team, "but we are not miracle workers, and we cannot test what we don't have: so we'd either need to buy a bunch of test devices or rely on people who already have an interest in using ARM and some ARM devices." There was never a consensus reached on the target hardware question (although ARM-powered Chromebooks seemed to be the most-asked-for device). The discussion of "deliverables" ultimately circled back around to the earlier question of what packages the ARM port needed to provide to meet the criteria staked out for promotion to PA. On that point, there still seems to be little in the way of agreement. Josh Boyer, for instance, opined that the criterion ought to be that one of the "release-blocking desktops" set out in the distribution release criteria; requiring all desktop environments would be overkill. Brendan Conoboy then asked how headless ARM servers could ever be acceptable as a PA if the criteria specify that KDE and GNOME (currently the only release-blocking desktops)are required. By the same token, server and cloud images would not be acceptable either. Garrett replied that a release which supported only headless servers would simply not be Fedora, a position that elicited strong reaction from others. Conoboy called it an "all or nothing" stance that serves to discourage further contribution and hurt Fedora's growth. "Maybe your Fedora means desktop OS, but my Fedora has more facets than that." Several people weighed in that the common public perception that Fedora is strictly defined as a GNOME-based desktop OS is largely the result of Fedora's history marketing that particular use case. Jiri Eischmann argued that ideally the project would present people with a range of options (e.g., desktop, server, cloud, etc.), and support whichever choice they make. DefinitionsBut redefining what Fedora is will clearly not be an overnight process. In the shorter term, the project does seem to be gearing up to re-evaluate the PA promotion guidelines. Despite all of the specific questions and objections raised about the ARM port's current status, the underlying issue comes down to whether PA status means recognition that the architecture has achieved parity with the existing PAs, or approval from the project to use the same resources as the other PAs—from build servers to the QA team's time. Garrett advocates staunchly for the former interpretation of PA status, saying "You don't get to be a primary architecture until you've demonstrated that doing so won't slow down the other architectures, and that requires you to fix all of these problems yourself first." Conoboy, on the other hand, wants PA status in order to improve the ARM port: "The ARM team isn't asking for a blessing, we're asking to have builds that block ARM also block x86. At a technical level, that is a fundamental part of what being primary is." In between lies quite a bit of middle ground. Nottingham complained that the F19 ARM release advertised a number of features (such as support for each of the major desktop environments) that were simply missing. But Toshio Kuratomi and others contended that the guidelines published were not intended to be blockers, but guides. Ultimately, as Williamson pointed out, the project can change its release criteria and its PA promotion guidelines to fit what the community wants—it just needs to decide first whether ARM is important enough to warrant that change. Fedora has considered promoting ARM to PA status in the past. At that time, Garrett posted a draft list of requirements for a secondary architecture to qualify for promotion; the current guidelines on the wiki are an expansion of that document. The ARM port has made considerable progress in the intervening time—a fact which Conoboy called attention to on a number of specific points. Still, as of now, no architecture has ever been promoted from secondary to PA; if ARM does so it will be breaking new ground. Gaining PA status would no doubt lead to improved testing and support, among other reasons for allowing the ARM team to offload some QA and other support work to Fedora's main teams, and concentrate on architecture-specific issues. For the time being, however, not much changes for the Fedora user interested in the ARM platform. As Daniel Berrange said, speaking as such a potential user, people who want to use Fedora on ARM are going to do so—regardless of whether it is branded a primary or a secondary architecture.
Brief items Distribution quote of the week
Basically, Debian is seriously behind the curve on this, but we're so used
to our familiar, comfortable problems that we don't necessarily see the
amount of pain that we're enduring that we don't have to endure. As
Charles noted elsewhere on this thread, once you start looking at and
maintaining either systemd or upstart configurations instead of init
scripts, you realize what sort of rock you were beating your head against
and how nice it feels for the pain to stop.
-- Russ Allbery
20 years of SlackwareAn interesting anniversary has just quietly slipped by: Slackware 1.0 was released on July 16 1993. Twenty years later, Slackware is quiet but far from dormant. Congratulations are due to what must certainly be the oldest still-maintained Linux distribution.
Fedora 19 for IBM System z 64bit official releaseFedora 19 for IBM System z has been released. For more information see the architecture specific release notes.
New Wayland Live CDs (with Wayland 1.2)A new ISO of RebeccaBlackOS, a live CD featuring Wayland and Weston, is available with Wayland and Weston 1.2.
Newsletters and articles of interest Distribution newsletters
New Debian leader seeks more innovation within project (ITWire)ITWire has an interview with Lucas Nussbaum, the new Debian Project Leader. "I see Debian as a two-sided project. On one side, there's a technical project aiming at building an Operating System, and doing that rather successfully. And one the other side, there's a political project, that puts Free Software very high on its priority list. This duality is quite unique: there are many successful technical projects that tend to not care very much about the political aspects, as well as some political projects that prefer to ignore the reality checks that we do on a regular basis."
Page editor: Rebecca Sobol |
|||||||||||||