Fedora 8 RC 3 was released three days ago. This RC shows what users can expect from the upcoming Fedora 8. It comes along with a huge list of new features and bug features. Among them are a KDE 3.5.8, a new NetworkManager core, PolicyKit, PulseAudio and RandR 1.2 support for the open ATI drivers.
The Fedora 8 Feature List was already known for several months, therefore this release does not come along with any surprising additions. Also, many of the feature are more or less designed for GNOME and do not directly apply to KDE users. Well, Fedora is a GNOME distribution through and through.
Nevertheless some of the features are cross-desktop features and are therefore usable for me as well.
KDE
First of all Fedora 8 ships with KDE 3.5.8. For me this means that I can again use Konqueror to edit my WordPress posts because a really annoying bug was finally fixed. Btw., it says a lot about Fedora and KDE when a bug report with patch isn’t even answered in 5 months.
And, of course, because this is real life, I cannot really enjoy WordPress at the moment because my personal bug #1 hits me hard right now. 
I really, really hope that this bug will be fixes with KDE 4. It would also be wiling to offer solid money if that means the bug gets fixed.
Fedora’s KDE version now also ships with the Enterprise branch of the KDE PIM suite which is said to be more stable.
Konqueror now also works again with the newest Flash player. The bug was automatically resolved by the update of the GTK packages since this was a GTK bug.
It doesn’t, I mixed it up.
NetworkManager
Fedora 8 ships with a pre-release of NetworkManager 0.7 which introduces a wealth of new features. However, it also introduces new APIs so that client tools have to be rewritten. KNetworkManager isn’t available yet so even the KDE version of Fedora 8 ships with the GNOME applet. As soon as knetworkmanager works with the new NetworkManager again it will be shipped through an update.
But for me the GNOME applet didn’t work either, it is still beta software after all.
PolicyKit
PolicyKit is described as “a framework for defining policy for system-wide components and for desktop pieces to configure it. It is used by HAL.”. Fedora’s feature page has a list of use cases for PolicyKit which might give a better impression:
- David wants to format his USB stick. When he activates the corresponding item from the context menu, the system presents a dialog asking him for the root password.
- Matt needs to adjust the clock of his computer. The context menu of the panel clock lets him do this without asking for passwords. (Or, depending on the policy, allows him to authenticate with his own password like sudo or Mac OS X.)
- When Ray shuts down his system, gdm asks him if he really wants to shut down while his girlfriend has a session running on the system. When he is the only user on the system, gdm shuts down without further questions.
- David administrates his familys desktop system. He wants to allow every family member to format removable media without giving them the root password. He achieves this by editing the xml file that defines the policy for PolicyKit.
In short PolicyKit helps to set end establish certain rights in the time of HAL and other, system wide available services and possibilities used on a multi user computer. Currently there is work done to integrate PolicyKit with GNOME. I haven’t heard of any work currently done to integrate PolicyKit with KDE, but this might come in the future. There is also work underway to create a KDE GUI for PolicyKit.
PulseAudio
PulseAudio is a sound server which is shipped with Fedora 8 by default and will be shipped with other distributions ins the future. It is supposed to be a drop-in replacement for GNOME’s ESD but is at the moment still desktop neutral (so could be used by KDE as well).
The role PulseAudio plays in comparison for example to GStreamer is best explained with X and GUI toolkits like GTK and Qt: PulseAudio is X, GStreamer or Xine are GTK or Qt. PulseAudio therefore won’t replace current existing solutions like Gstreamer or Xine but will sit between these and ALSA to improve the handling of sound streams at that point.
PulseAudio will pave the way for intelligent audio hotplugging functionality—making it possible for the system to automatically redirect VoIP program audio streams when users plug in or remove USB headsets, for instance. PulseAudio’s support for network transparency will also facilitate some impressive functionality.
[…]
PulseAudio would make it possible for a VoIP program to automatically reduce the volume of music programs when a call starts. The software could also be used to automatically reduce the audio volume of all windows that aren’t in the foreground so that if you are playing two movies simultaneously, for instance, the movie in the active window would have higher volume
This however reminds me of some feature KDE’s Phonon is supposed to offer. I wonder how well it will work when two Audio related programs/layers will try to reduce the music audio output because a VoIP call is coming in.
But in case of KDE the discussion isn’t that interesting anyway: Phonon clears the way for every development which might come up. Even if PulseAudio suddenly is extended and tries to replace Gstreamer one day (which is unlikely) KDE 4 could still use it. Thanks, Phonon.
Nevertheless I still have problems with the word “Sound Server”. KDE once had a sound server and while it was a masterpiece at its time it was the source for multiple problems at the end of its lifetime. While there are lengthy mails about all possible problems of PulseAudio I’m still not convinced that the introduced latency will not have any impact on my experience watching Flash movies or talking via Skype. I would like to see some benchmarks or tests or something on standard hardware (!) in that regard.
RandR 1.2 and free ATI drivers
Fedora 8 finally ships with free ATI drives which support RandR 1.2. And it works indeed: the resolution and the ouput of the screens can be altered at the fly. A simple
xrandr --output LVDS --off --output VGA-0 --mode 1680x1050
turns off the Laptop screen and sets the external monitor to 1680×1050. There is no restart or additional xorg.conf configuration necessary. There is still a GUI missing thought, but I’m pretty sure that one will be shipped with Fedora 9.
So, finally I can use hotplug with my external monitor.
Other improvements
Fedora 8 comes along with various other improvements. There is for example a new firewall configuration application which is simple but covers the important parts. Also, the bootup is notably faster, and there is of course a new Kernel.
For KDE enthusiasts the next version of Fedora might be more interesting though because that one will most likely ship with KDE 4. Currently there are just the development libraries available in Fedora 8.
/home/liquidat 
It’s a very simple/true question from someone that does not know fedora and wonders why some strong KDE suporter like you uses “a GNOME distribution through and through.” ?
It’s not if like KDE friendly distro doesn’t exists. So why make you use fedora ?
OT: mhh. On planetkde, your headlines are not shown, instead the alt tag of the picture is used for that…
gaboo: Because I use the command line very much anyway and I am quite used to the Fedora specific tools like RPM/yum.
OpenSuse would be the alternative for me, but last time Yast altered the configuration lines too much.
Kubuntu would also be an interesting alternative, but then again the entire system administration is quite different. Plus, I never figured out how to install just all apps having the string “font” via apt.
@Robin: Yes, I now that, a fix is already available for the planet parsers, but isn’t applied everywhere atm.
I always wonder how Fedora manages their upgrade paths in such cases.
If you were using KNetworkManager before, do they remove it or do they leave an incompatible version in your system.
If they remove it, how do they remember to install it again when its compatible version becomes available.
Well, I guess they could just silently remove it and have you know and remember that they’vew done that, but I wouldn’t call that an “upgrade path”.
It seems that an increasing number of distributions sacrifies system feature stability for this time based release strategy.
gaboo: well, there are no big problems using KDE on Fedora. It’s on the install-DVD and a liveCD exists for it too. It’s only that some desktop-specific stuff is sometimes missing or in an earlier state on KDE.
As liquidat pointed out already, OpenSUSE and Kubuntu are possible alternatives, but they just don’t have the same look’n’feel. Most of use Fedora/KDE supporters use this distribution for some years already – most of us even used red hat linux before (I myself started with rhl 7.x). KDE was better supported back then and we hope to make it more important inside Fedora again (the KDE SIG is doing its best to do so).
Kevin:
There is a wrapper package called knetworkamanger which pulls in the necessary dependencies for the gnome tool but also makes sure that later on it can be replaced by a “real” KDE knetworkmanager.
Of course this leads to problems: the gnome keyring manager must be used in the meantime, so you have to enter all passwords again when the program is replaced, so in case of an update this might happen two times.
And you will have some unnecessary packages afterwards on your machine, but since most of it is installed on such machines anyway it is ok, I think.
Kubuntu is just the KDE version of Ubuntu, much like Fedora-KDE-Live is the KDE version of Fedora. There was a recent post on PlanetKDE by a Kubuntu developer bringing up problems with Ubuntu’s GNOME-centricness that sounded very familiar to me as a Fedora KDE SIG (Special Interest Group) member. So I don’t think things are really better over there, they’re just better at hiding the problems with strong marketing.
Ah, such a dummy-package is a nice idea and I don’t think that remaining packages after restoring the functionality later on is a problem either, probably removable automatically since no other package depends on it anymore.
The thing about loosing all your authentication info is bad though, especially since it will basically “remove” the automatic connect feature, i.e. network manager connecting to a known WLAN without any interaction.
Would have been better to either access the KDE authentication store or provide a converter/importer.
Will there be some 8.x release when the situation is resolved or should admins that deploy Fedora for non-tech users wait for release 9?
We hope to have a working KNetworkManager in an F8 update.
OK, good to know.
Sometimes people mistakingly ask for help on such issues in upstream channels and it is a lot more pleasant to be able to tell them that a solution is being worked on and will be available in an update later on.
Anyway, a good example on how the time based release isn’t that good either. A multi component feature can either be release only partially working and “fixed” in an update or has to be postponed for a full release.
They wouldn’t have waited for KNetworkManager to get updated anyway (which rejoins the issue of GNOME-centricness). At least with the time-based model, they won’t wait for the GNOME folks to complete a feature either, so this actually gives us fairer treatment.
Lets say I find it hard to imagine that they would have released an updated Networkmanager even if the GNOME UI wouldn’t have been updated in time.
I understand that Fedora has evolved quite a bit from basically being Redhat’s experimental branch to being a distribution on its own and it will be interesting to see if it will evolve further, probably managed by a community of equals rather than ruled top-down, i.e. a bit like a “time-based releases” equivalent to Debian.
Kevin: There is quite a strong community involvement inside of the Fedora project. Many of the most important people are not employed by Red Hat. But all these people – except Rex Dieter – love GNOME. Even the user base of Fedora are mostly GNOME users.
I don’t see much of difference in people being employed or not being employed to work on the distribution, unless of course the employers leverages the situtation to force their agendas, it’s more a difference in the decision process.
It is not necessarily bad when some people have more power than others and it might not be a goal of the project to evolve to a stage where breaking someone else’s packages is no longer an option, that’s why I wrote it will be interesting to see *if* it does.
The Fedora KDE people have done an awesome job so far, tranforming the situation from ignorance to tolerance, especially Rex who is additionally a valuable member of upstream’s user support.
It’s quite unfortunate that their work is not as much appreciated by their own peers in the project, when decisions like this one pretty much tell them that their work is as low of importance than yet-another-icon-set and that their users have to be prepared to be collateral damage now and then.
As an outsider I guess there is something unbelievably great in running a Fedora system otherwise I can’t imagine why KDE packagers and users would go along with this. Probably running a distribution with backing by a big corporate distributor and still having high quality KDE packages with only resonable patches applied.
“I don’t see much of difference in people being employed or not being employed to work on the distribution, unless of course the employers leverages the situtation to force their agendas, it’s more a difference in the decision process.”
Not just a matter of decision process. You are oversimplifying the process. People employed by a Linux vendor (assuming that they are employed to work on that specific area) will be able to spend more time working on a harder problem or meet a deadline quickly compared to someone who volunteers to do a job. Having that as a general rule, what Red Hat developers working on Fedora do influences Fedora to quite a large extend merely because people who do the work tend to drive the direction of Free software projects. There is no force of agenda necessary in these instances.
thanks for the update info!
Would be nice if the password manager core was cross-desktop compatible with different UIs. Seems like thats the way a lot of projects are going these days, and a password manager would be ideal for that.
Leo S: Funny, I had the same thought these days. It would be good to transport this information via a non-desktop specific way (D-BUS?).
Think of a general password manager which even integrates with Firefox – that would be awesome!
“You are oversimplifying the process.”
First, the statement was a weighting, i.e. that the decision process is more important than coporate involvment.
Second, I was reacting to a misinterpretation of an earlier posting, i.e. that I am not worried about Fedora people being employed by Redhat, since I pretty confident that RH does not excert control bypassing the usual process.
Obviously developers working full-time on a feature set will be more predictable, but this essentially implies that their potential progress can not be used as reference for decisions about inclusing or postponing of features if there are part-time developers involved as well, unless the full-time developers are schedules to help the part-time developers once their own work is completed.
Of course it is the employer’s choice to do this or to have their employees do something else company related once they are finished, however a project such as Fedora is either a community project, thus has policies that make it possible for volunteers to contribute, or they are just a proxy, thus following the company’s polices and not caring that much about volunteer contributions (obviously for marketing reasons this would not be the official course)
Now, as I said above, I am confident that Fedora actually is a community driven and community governed project, thus quite certainly determine a possible feature set for a new release based on varying developer time.
Unfortunately it seems that this time the estimates were too far off, but instead of properly handling the delay (either by delaying the release or by postponing the feature to the next release), falling back to this weird “break now, repair later”
Having been raised in a country where at least according to law people are to be treated equally, it is not easy to understand that an international community can build and maintain a project based on different classes of users, where it is OK to break things for a second class minorty if it means more luxury for the first class majority.
Obviously being a second class Fedora user is still considers to be better than being a user of another distribution.
“It would be good to transport this information via a non-desktop specific way (D-BUS?).”
Depends on the semantic difference between the key stores. Both (gnome-key-ring and KWallet) use D-Bus anyway (in case of KWallet in KDE4 through kded, into which it is loaded as a plugin).
i prefer to use ubuntu than fedora
There’s a typo in the xrandr command line, it only has one dash before “–output”. I noticed since my cut-and-paste didn’t work. 🙂
It should be:
xrandr -–output LVDS -–off -–output VGA-0 -–mode 1680×1050
Finally I can reliably use a projector.
joshuadf, that typo is due to a bug in the wordpress software. But thanks anyway.