There a number of new features, enhancements and improvement coming up in Fedora 11. Here are just a few of those:
- Filesystem - Ext4 is the now the default FS in Fedora. The ext4 filesystem has more features and generally better performance than ext3, which is showing its age in the Linux filesystem world.
- Fingerprint - Extensive work has been done to make Fingerprint readers easy to use as an authenticaton mechanism. Currently, using Fingerprint readers is a bit of a pain, and installing/using fprint and its pam module take more time than should ever be necessary. The goal of this feature is to make it painless by providing all the required pieces in Fedora, together with nicely integrated configuration.
- Presto (Delta RPMs) - Support for the yum Presto plugin which will give users the option of not downloading whole package updates and instead using Delta RPMs to build packages locally. This will enable users of dial up connections and others in network-scarce environments to keep up-to-date.
- VolumeControl - The multimedia experience of Fedora users is improved by an easily understandable and much more flexible volume control model. With the use of PulseAudio by default, it makes sense to no longer expose the unintuitive plethora of volume controls and channels that alsa exports, and which is currently reflected 1-1 in the gnome volume control tools (gnome-volume-control and mixer applet). PulseAudio already ships with a volume control app, pavucontrol, that is packaged for Fedora (but not installed by default).
- TightVNC - TightVNC has successfully implemented "Tight" protocol enhancements which save bandwidth and are generally better than the original RealVNC's RFB 3.8 protocol. On the other hand Fedora vnc has by far a much better server (Xvnc) which is based on X 1.5 and supports more extensions. Fedora changes have to be carefully merged to TightVNC upstream and then we will use it as default Fedora vnc system.
- Cups Policy Kit Integration - Cups has its own authentication and policy configuration mechanism, which basically consists in specifying users/groups that are allowed administrative access to the cups server. In an ideal world, cups would expose its administrative functions as a PolicyKit mechanism via d-bus. Since that is unlikely to happen in the short term (if ever), Vincent Untz of OpenSUSE has written a small wrapper called cups-pk-helper to do this, together with the necessary changes to pycups and system-config-printer to talk to cups-pk-helper instead of directly to cups.
- Simple Security Services Daemon - The SSSD is intended to provide several key feature enhancements to Fedora. The first and most visible will be the addition of offline caching for network credentials. Authentication through the SSSD will potentially allow LDAP, NIS, and FreeIPA services to provide an offline mode, to ease the use of centrally managing laptop users. Laptop users will have offline access to their network logons, eliminating the need for local laptop accounts when traveling. Desktop developers will have access to the new InfoPipe, allowing them to migrate towards using a more consistent approach for storing and retrieving extended user information.
- DeviceKit - DeviceKit is a simple system service that a) can enumerate devices; b) emits signals when devices are added removed; c) provides a way to merge device information / quirks onto devices. It is designed to partially replace hal and overcome some of the design limitiations of hal. DeviceKit functionality is provided in the form of dbus services on the system bus.
- IBus - iBus is a new input method framework under active development which is designed to overcome the limitations of SCIM. It will be the default in Fedora 11. iBus uses dbus protocol for communication between the ibus-daemon and clients (engines, panel, config tools). Since the components run in separate processes there is enhanced modularity and stability. Client processes can be loaded, started and stopped independently. iBus supports Gtk2, Qt4, and XIM, and has input method engines for anthy, chewing, hangul, m17n, pinyin, and large tables. Engines and clients can be written in any language with a dbus binding.
Development Oriented Features
- Python 2.6 - Fedora is about pushing the boundaries, and having Python 2.6 as a transitional release on the path to Python 3000 is no exception.
- Archer - Archer is a gdb development branch focusing on better C++ support. It also includes Python scripting capabililites. More information at http://sourceware.org/gdb/wiki/ProjectArcher
- DNS Security - DNSSEC (DNS SECurity) is mechanism which can provide integrity and authenticity of DNS data. It became more important after new Kaminsky DNS poisoning attacks were found in early 2008. The most widely used name servers support DNSSEC, though it is only (bind, unbound). Our servers and clients will be "invulnerable" against cache poisoning, Kaminsky attacks, spoofing and other known DNS attacks.
- KVM PCI Device Assignment - KVM guests usually have access to either virtio devices or emulated devices. If the guest has access to suitable drivers, then virtio is preferred because it allows high performance to be achieved. On host machines which have Intel VT-d or AMD IOMMU hardware support, another option is possible. PCI devices may be assigned directly to the guest, allowing the device to be used with minimal performance overhead. In summary, PCI device assignment is possible given the appropriate hardware, but it is only suitable in certain situations where the flexibility of memory over-commit and migration is not required. Fedora users will be able to assign PCI network cards, hard disk controllers, phone line termination cards etc. to their virtual machines.
- [[[Features/Windows_cross_compiler|Windows Cross Compiler]] - The Fedora MinGW project's mission is to provide an excellent development environment for Fedora users who wish to cross-compile their programs to run on Windows, minimizing the need to use Windows at all. In the past developers have had to port and compile all of the libraries and tools they have needed, and this huge effort has happened independently many times over. We aim to eliminate duplication of work for application developers by providing a range of libraries and development tools which have already been ported to the cross-compiler environment. This means that developers will not need to recompile the application stack themselves, but can concentrate just on the changes needed to their own application.