With Fedora 17 freshly released, the project has turned its attention
to deciding on a feature set for Fedora 18. Among the approved
changes so far are mounting /tmp in RAM, a better "hotspot"
mode for WiFi connection sharing, a rewritten graphical installer, and
a reorganization of the package categorization system.
New Fedora features must be approved by the distribution's Engineering
Steering Committee (FESCo), which discusses them during its weekly IRC
meetings. The approved
list resides on the Fedora wiki. At the moment, it lists 14 items
— but there are a few more recent additions, plus some proposals
still in limbo. Proponents will have until July to make their cases
for additional features.
Several of the items are mundane, such as bumping a major package to
the newest upstream version. Individual packages rarely merit a
hearing by FESCo, but the group weighs in where it concerns major
projects (such as desktop environments) or packages that affect a
large number of dependencies (such as programming languages,
compilers, or packaging). Among those key package updates for Fedora
18 are Xfce 4.10, the Glasgow Haskell Compiler (GHC) 7.4, Boost
1.50.0, RPM 4.10, and the Perl-Compatible Regular Expression (PCRE)
Other system infrastructure pieces receiving a change in Fedora 18 are
Kerberos and Red Hat's GlusterFS filesystem. The Kerberos package
will move its cached credentials from /tmp/ to under
/run/user/, while GlusterFS will be incremented to version
3.3. GlusterFS is designed to work with Red Hat's OpenShift cloud
computing platform, which will also be added to Fedora 18. The
package added will be OpenShift Origin, which is the community version
of the OpenShift product.
The distribution also wants to make Fedora machines work with
Microsoft Active Directory domains out-of-the-box, a project
that involves configuration and bug fixes in a variety of packages.
Kerberos configuration is among them, but the fixes target SSH, NTP,
and an array of other tools.
User-visible desktop features
Fedora's installer is called Anaconda, and a visual and architectural
overhaul has been in the works since 2011. According to the wiki, the
user interface has not been updated in six to seven years, which makes
it badly in need of a new coat of paint, but there are also
architectural limitations to the design that make it difficult to add
new features (both for Fedora itself and for downstream distributions).
The plan is to rework the installer according to a "hub and
spoke" design, in which only a few configuration screens are
mandatory and demand user input, with optional configuration screens
accessible for those who need them. GUI mock-ups and other design
documents are on the wiki.
A side-effect of the overhaul is that the text-mode version of the
installer will be dropped for Fedora 18, and slated to reappear for
A related change is the refactoring of the distribution's package
groups. These are the metadata-defined blocks of related packages
that users can use to install sets of applications and libraries that
serve a related need. Years ago, installing packages in such blocks
was the norm in most distributions, but Fedora's group definitions
have drifted out of alignment with the components that actually serve
as the "building blocks" for Fedora itself and its "spin"
derivatives. Refactoring the groups should ease maintenance in the
long run, but implementing the change involves a lot of package
A practical change on the feature list is a new, easy-to-use WiFi
hotspot mode in NetworkManager. This is a feature used for turning
the computer into a WiFi access point to be shared with other
devices. The existing version of the hotspot-sharing mode uses WiFi
Basic Service Set (IBSS) ad-hoc mode, but in practice ad-hoc mode
is not reliable (particularly if WPA or WPA2 is activated). As a
result, many consumer devices refuse to connect to ad-hoc networks.
The new hotspot mode will in essence let the Fedora box function as a
standard WiFi access point (AP). Allowing Fedora to present itself as
an AP will make connection sharing work with these devices.
System component updates and migration
Fedora 18 will also move /tmp to a tmpfs filesystem in RAM
by default. As we covered last week,
there are pros and cons to this approach, but FESCo decided that
tmpfs-backed /tmp offered more benefits in the common case
than downsides. The option to store /tmp on disk will still
be provided. Interestingly, one of the main reasons cited for the
Kerberos cache move mentioned earlier was that /run/ is a
tmpfs filesystem and will vanish when the machine is rebooted,
offering better security — but if /tmp moves to tmpfs,
too, users will get the same added security they would from moving
Kerberos's cache to /run.
There are other system components being refreshed in the new release.
One is migrating access control to privileged operations entirely to
PolicyKit. The usermode package, which includes userhelper,
userinfo, usermount, and userpasswd, is one
of the last holdouts. These tools are setuid root shims around
existing system tools, and will be replaced with PolicyKit-managed
access to the underlying programs.
The procps tools are also marked for replacement, in this case by the
rewritten procps-ng suite. Procps is the suite of utility programs
that report on and manage process information: ps,
top, kill, free, and so forth. Fedora's
"legacy" version of these utilities long ago diverged from upstream
with a series of distribution-specific patches, to the point where
they can no longer be re-merged. The procps-ng utilities are a
to provide better message and error printing, exit codes, and cleaner
behavior all around.
Finally, as we discussed in greater
depth elsewhere, Red Hat's Matthew Garrett is implementing support for
UEFI's secure boot for Fedora 18. The plan involves
purchasing a secure boot signing key for the project and making
changes to the bootloader and kernel module-loading process to permit
only signed binaries to boot on secure boot hardware.
More to come
FESCo recently ratified the release schedule
for Fedora 18, which gives contributors until the first week of July
to propose new features for inclusion, aiming for a final release at
the end of October. There are a few still under consideration that
may make the cut before the deadline, including adding ARM as a
first-class architecture and a new first-run tool.
Promoting ARM support to the first tier would mean treating ARM
equally alongside i686 and x64_64 in the project's build system.
Proponents of the feature argue that although ARM devices vary in
their capabilities, including many low-power devices without
floating-point support, there are enough general-purpose desktop and
laptop machines capable of serving as everyday PCs to warrant ensuring
that Fedora runs on them. They also point out that ARM-based servers
will come to market in the not too distant future. The promotion is a
major undertaking, though, including
hardware changes in Red Hat's build facility, plus extensive QA work
on everything from the kernel to Anaconda. The idea has its
supporters, but it could prove too ambitious for this cycle.
The new first-run tool is documented as the Fedora Initial
Experience. It encompasses post-installation setup, from license
notices and networking setup to online account configuration and a
tour of the GNOME 3 desktop. The specification is for some of these
Initial Experience steps to replace the normal GDM login after
installation. However, there remain issues to be sorted out, including
how to make setup tasks optional and how to smoothly transition
between the Initial Experience and a regular login session.
With around one month to go, there is still plenty of time to add to
the feature list; there may be new surprises or the reanimation
long-delayed efforts like Btrfs-by-default or LXC containers. Thus
far, Fedora 18 is taking on a smaller set of changes than those
tackled in Fedora 17 — though some of them are of greater
significance than a single bullet-point on a list suggests. The
OpenShift features and ARM support would even the distribution with
Ubuntu's offerings in those areas, which is clearly of interest to
both the community and Red Hat. On the other hand, the UEFI secure
boot feature has already spawned considerable debate, as has the
/tmp move to a lesser degree. How those debates shake out
will be interesting to watch over the coming six months.
to post comments)