Fedora upgrades ARM support, now treats it as x86’s equal

No future Fedora release gets out the door without fixes to ARM bugs.

Fedora 20 was released today, with support for ARM as a primary architecture. While x86 will still be the default for most Fedora users, classifying ARM as a primary architecture means that "it receives the same amount of attention that the x86 and x86-64 releases get," Fedora Project release notes say.

When ARM was treated as a secondary architecture, new versions of Fedora could be released if there were problems with ARM but not x86.

"Build failures on [primary] architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture," the Fedora Project notes. "To put it simply: These are the architectures for which Fedora will delay a release if they are not functional. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd)."

"ARM is rapidly growing in stature and already dominates the mobile world," the Fedora announcement said. "Beyond mobile and the maker movement, ARM shows great promise as a powerful and cost-effective technology for the server world, leading to primary support from Fedora to satisfy end users and developers targeting the ARM platform."

In addition to improved ARM support, Fedora's announcement details improvements for cloud and virtualization deployments, developers, and desktop users. New "first-class cloud images" are "well-suited to running as guests in public and private clouds like Amazon Web Services (AWS) and OpenStack." Another new feature makes it easier to take snapshots of virtual machines.

Developers will appreciate WildFly 8, which was previously called JBoss Application Server. The software "makes it possible to run Java EE 7 applications with significantly higher speed. It boasts an optimized boot process that starts services concurrently, preventing unnecessary waits, and taps into the power of multi-core processors. Additionally, WildFly takes an aggressive approach to memory management and keeps its memory footprint exceptionally small compared to other JVMs."

Ruby on Rails 4.0 is also included in Fedora 20.

For desktop users, GNOME 3.10 brings "a new music application (gnome-music), a new maps application (gnome-maps), a revamp for the system status menu, and Zimbra support in Evolution."

"ARM is rapidly growing in stature and already dominates the mobile world," the Fedora announcement said. "Beyond mobile and the maker movement, ARM shows great promise as a powerful and cost-effective technology for the server world, leading to primary support from Fedora to satisfy end users and developers targeting the ARM platform."

There are some holes in this announcement. What is their main intent?

Is it all about the future? Is this of the "If we build it, they will come" variety.

Who is going to use this now? I understand the point of planning for the future, but I don't currently own an ARM device that's not a phone or tablet. Have they done the legwork to make this usable?

As far as servers go, I thought they were the realm of RHEL. So is this move with Fedora a prelude to improving RHEL ARM support?

"ARM is rapidly growing in stature and already dominates the mobile world," the Fedora announcement said. "Beyond mobile and the maker movement, ARM shows great promise as a powerful and cost-effective technology for the server world, leading to primary support from Fedora to satisfy end users and developers targeting the ARM platform."

There are some holes in this announcement. What is their main intent?

Is it all about the future? Is this of the "If we build it, they will come" variety.

Who is going to use this now? I understand the point of planning for the future, but I don't currently own an ARM device that's not a phone or tablet. Have they done the legwork to make this usable?

Who is going to use this? All those people ARM is trying to sell their new Aarch64 processors for power efficient servers mostly.

You can't wait until the hardware is out and available before starting to work on such a project - runtimes (say the JVM), compilers, OSes and god knows what else have been working on ARMv8 support for years by now.

The article doesn't mention ARMv8 especially (and haven't looked up the original sources), but I know Fedora/Red Hat has been working on that for a while and since anything before that wasn't really going to end up in many desktops/servers it's probably correlated.

"ARM is rapidly growing in stature and already dominates the mobile world," the Fedora announcement said. "Beyond mobile and the maker movement, ARM shows great promise as a powerful and cost-effective technology for the server world, leading to primary support from Fedora to satisfy end users and developers targeting the ARM platform."

There are some holes in this announcement. What is their main intent?

Is it all about the future? Is this of the "If we build it, they will come" variety.

Who is going to use this now? I understand the point of planning for the future, but I don't currently own an ARM device that's not a phone or tablet. Have they done the legwork to make this usable?

As far as servers go, I thought they were the realm of RHEL. So is this move with Fedora a prelude to improving RHEL ARM support?

ARM is used in a lot of places people don't suspect, particularly embedded.

I've been running opensuse on Arm. But when I evaluated the market about a year ago, Ubuntu was the most stable on Arm. Opensuse was as stable, but wasn't as refined in handling the GPU at the time. (Package management on Opensuse is vastly superior to Ubuntu, hence my choice.) But Fedora was very much lagging the rest of them.

I wonder how long before we see something like "fone-dora", Fedora ported to run on smart phones?

Fedora already defaults to KDE Plasma on ARM. Plasma2 will directly integrate Plasma Active, KDE's touchscreen DE (it's currently a separate product for technical reasons).With Jolla Sailfish, Ubuntu Touch, and even BlackBerry 10 all using Qt as toolkit as well, some phone-related technology that can be picked up by KDE should be available.

"ARM is rapidly growing in stature and already dominates the mobile world," the Fedora announcement said. "Beyond mobile and the maker movement, ARM shows great promise as a powerful and cost-effective technology for the server world, leading to primary support from Fedora to satisfy end users and developers targeting the ARM platform."

There are some holes in this announcement. What is their main intent?

Is it all about the future? Is this of the "If we build it, they will come" variety.

No. We've had working ARM on Fedora on various platforms for three or four releases. The news for F20 is that it's reached the point where we can support it as a primary arch, whereas it was secondary before (which meant its packages got built in a separate build system - so packages weren't rejected from the main build system if they failed on ARM - and we didn't block releases on it working, and its release could be delayed from the main release.

Who is going to use this now? I understand the point of planning for the future, but I don't currently own an ARM device that's not a phone or tablet. Have they done the legwork to make this usable?

Those aren't the kind of devices Fedora is currently targeting, for a variety of reasons. One, Fedora's very much a do-ocracy, and the folks leading the ARM efforts are more interested in dev boards and server platforms than tablets and phones. Two, tablets and phones aren't a hugely interesting target for Fedora in the first place because there isn't much interesting tablet/phone hardware which can plausibly be made to work well enough to be usable without out-of-tree and/or proprietary drivers, neither of which Fedora allows. (And we don't have a really tablet- or phone-friendly desktop to run even if we had viable hardware).

Fedora is more focused on dev platforms at the moment: stuff like the RaspPi (though our ARM devs don't like the Pi very much; we can't support it in mainline Fedora as it needs out-of-tree kernel stuff, there is a remix of Fedora for the Pi instead), BeagleBone Black (our current main target platform), Wandboard, Trimslice, and some Calxeda platforms. https://fedoraproject.org/wiki/Architec ... #Fedora_20 has details and links to the installation instructions for the various most-supported platforms.

Exactly how 'usable' it is is rather platform-dependent, but the Trimslice for instance can run a full graphical desktop and all its hardware works. The BBB is our current 'premier' target platform, but it wasn't quite in as good state as the Trimslice for F20 release; notably, the HDMI doesn't work. (This isn't as bad as it sounds, as people who tinker with ARM dev boards are quite used to using a serial console as their main interface). The currently-impending 3.12 update kernels for F20 should provide just-about-full functionality on the BBB, and the ARM team will likely provide an unofficial updated F20 image with a 3.12 kernel for the BBB. See https://fedoraproject.org/wiki/Common_F ... eagle-bone .

As far as servers go, I thought they were the realm of RHEL. So is this move with Fedora a prelude to improving RHEL ARM support?

That's not really entirely accurate - plenty of people do run servers on Fedora, actually, though they're usually slightly insane people, like me. happyassassin.net is all Fedora all the way down (several Fedora VMs running on a Fedora KVM host). Fedora isn't necessarily meant to be a platform most people would be interested in running mission-critical long-term server deployments on, but it definitely is a platform people will be interested in running short-term, experimental deployments on, or a personal setup they want to experiment with, say.

Let's say if you're a person who's interested in the potential of running long-term mission-critical deployments on ARM servers running RHEL in a few years, you may well be very interested in experimenting with test deployments running on Fedora right now. That's one target of the Fedora ARM stuff. Another major target is, of course, people who just want to tinker with ARM dev hardware and see what cool stuff they can come up with, or contribute to improving ARM development work.

I've been running opensuse on Arm. But when I evaluated the market about a year ago, Ubuntu was the most stable on Arm. Opensuse was as stable, but wasn't as refined in handling the GPU at the time. (Package management on Opensuse is vastly superior to Ubuntu, hence my choice.) But Fedora was very much lagging the rest of them.

That's...not really fair.

Let me be careful how I phrase this, because I don't want to come across like I'm slagging SUSE or Ubuntu. Everyone's doing work that's valuable for someone, with a somewhat different focus. But I think your assessment is unfairly negative towards Fedora.

Ubuntu is doing the kind of thing a distro like Ubuntu or Mandriva should be doing: trying to hack together something that's usable for 'ordinary users' on 'consumer devices' right now. This involves quite a lot of messy hacking and compromises. If you want something that runs on a typical consumer (not developer) ARM device right now, with a shiny graphical UI that's useful for regular users, you're going to have to make some compromises, like using out-of-tree and proprietary drivers. Particularly for graphics. That's the kind of work Ubuntu has been focusing on.

Fedora hasn't been doing that, because Fedora isn't that kind of distro. Fedora has always been more about working on the clean, long-term 'right way' of doing things. So no, we don't have a build of Fedora 20 with a bunch of proprietary and out-of-tree drivers hacked together quite messily in order to get something that runs on a Nexus 4. That's not really what Fedora's for.

Fedora instead has been working on stuff like the the unified ARM kernel effort (for many releases, the ARM stuff in the kernel was a horrible mess with different trees for different platforms; Fedora's been contributing to cleaning that up) and getting drivers properly open sourced, cleaned and integrated in the upstream kernel. It's a slower, longer haul and it produces less SHINY SHINY in the short term, but it is equally valuable work.

Again, please don't construe the above as an attack on Ubuntu or any other distro: the hacking-things-together-in-the-short-term stuff really is valuable work, in that it's better to have a Linux distro that's a bit hacked together that works than not really to have anything that works at all. But Ubuntu is there to be Ubuntu, and Fedora is there to be Fedora, and it works out better for everyone in the long run if we each do our different types of work rather than both do the same thing.

Wow a new music application. So how many times has the music application been replaced in Gnome over the past 15 years? 8 or 9 times?

What's the matter with these people that they have to keep rewriting everything from scratch over and over again?

Um. I think your memory might be a bit clouded.

GNOME has never quite officially blessed a single music player. Rhythmbox was the de facto standard for a long, long time and was proposed for inclusion in GNOME 2.x several times but never quite went all the way. Distros often shipped it as part of their GNOME package sets, but that wasn't the same as GNOME considering it "the official GNOME music player".

There have been other GNOME-y music players - Muine and Banshee are the ones that leap to mind - but it's not as simple as GNOME keeping on rewriting 'their own official music player' from scratch. Each of those was written by different people for different reasons, and I think only RB ever explicitly aimed at becoming the 'official' GNOME music player.

Even today, if you go to http://www.gnome.org/ , it doesn't really have an 'official music player'. It lists both Banshee and Rhythmbox on the 'great applications you can use on GNOME' page - http://www.gnome.org/applications/ - with the same sort of status as Inkscape or the GIMP, neither of which anyone would mistake for a 'GNOME project'.

So yeah, there's been some churn in GNOME music players, but a) nowhere near as much as you suggest, from my memory and Googling around some list archives, and b) it's never been as simple as there being a single official music player which keeps getting re-written.