Fedora 11: Virtual(ization) Reality

Cutting edge virtualization technology has always been one of Fedora's strong suits and Fedora 11 looks to continue that trend. In an interview with Daniel P. Berrange, Red Hat Virt Team Engineer and Fedora Virtualization guru, we talk about the many key upgrades to virt technology in F11 focusing on areas of usability, performance and security. Fedora 11 will premiere the latest in secure and powerful virtualization technology available to users and developers. With so much to look forward to Fedora 11, it's sure to make your virtualization dreams a reality.

1. Please introduce yourself, and tell us about your work in virtualization and how you got started.

I'm one of the lead developers for the libvirt project and am actively involved in many related areas of open source development (qemu/kvm, xen, gtk-vnc, virt-manager, to name but a few). I also co-maintain many of these packages in Fedora and RHEL, along with many others in Red Hat's virtualization team.

More than three years ago (shortly after transferring into Red Hat's Engineering team, from consulting services) I was working on the OLPC project. We needed a way to easily test the OS images we were building without needing real hardware. As a proof of concept, I hacked up a simple GTK application to run images them under QEMU. At around the same time Daniel Veillard had started the libvirt project and there was a desire for a desktop application to manage Xen using libvirt. So I switched over to the virtualization team, wrote virt-manager for Fedora 6, and my involvement in all areas of open source virtualization grew from there.

2. Many people view the work being done on virtualization as a feature set of major importance and significance. Can you give us a brief overview of some of the changes we can expect to see in Fedora 11?

The open source virtualization development effort is so large now, that it is useful to discuss each stream in turn.

At the lowest layer is obviously the Linux kernel and KVM/QEMU. There has been a major acceleration of development in QEMU and push to merge KVM into the official QEMU source repository. There's ever continuing work on performance, stability, scalability and reliability in KVM. PCI device passthrough is one new feature we're highlighting for Fedora 11. The return of Xen Dom0 was not to be, as the Dom0 paravirt_ops merge with the upstream Linux kernel is still an ongoing process.

At the middle layer is libvirt, providing a consistent management API across different virtualization technologies. New features in libvirt, since F10, include PCI device passthrough for Xen and KVM, the sVirt security driver using SELinux to protect KVM guests from each other, thread safety of all libvirt APIs, improved scalability, reliability and debugging for the libvirtd daemon and support for SCSI HBAs and copy-on-write volumes in the storage management APIs.

The top layer covers end user tools such as virt-install and virt-manager. virt-manager is undergoing a significant (and ongoing) overhaul of its user interface. The first improvements arriving for Fedora 11 are in the guest installation process and storage management capabilities. As guest installation is first task most users try, ensuring this is simple and reliable is key to making a good first impression. Guest desktop interaction is another historical pain point which has been a focus for improvements in Fedora 11.

With every release we also try to make a significant step forward in security of the virtualization stack. In Fedora 11 the focus has been on SELinux to protect guests from each other and SASL to authenticate VNC users.

3. There have been some large changes in virt-manager and libvirt, which are at the core of the user experience when it comes to virtualization. Can you talk to us more about those?

The guest installation process and desktop interaction are the most critical areas for making a good first impression. In the virt-manager re-design the wizard used for installing new guests has been streamlined, cutting out three redundant steps. Where possible, it will automatically detect the type of operating system being installed and choose the best configuration options to optimize for this OS, no longer requiring the user to figure this out for themselves.

The installation process now directly utilizes the libvirt storage management APIs to allow easy creation of files in a variety of formats (raw, qcow2, vmdk, etc), allocation of new local disk partitions or LVM volumes and access to LUNs exported by iSCSI targets. This is particularly useful when remotely managing virtualization hosts, allowing regular administrator tasks to be performed from the virt-manager UI without resorting to command line SSH sessions.

The mouse pointer has been a constant source of trouble for virtualization management applications. Getting the guest mouse pointer to track the host pointer is essentially impossible with the standard emulated PS/2 mouse. The solution is to provide a pointer device that supports absolute motion events, instead of relative events that the PS/2 mouse provides. For KVM and Xen, this means adding a USB tablet device, but historically Xorg has not been able to automatically configure this correctly. This is resolved with Fedora 11 guests, finally providing a guest pointer that moves in perfect sync with the host, not requiring the pointer to be confined to the guest window.

Users with non-US layout keyboards have also had a hard time getting their guests to support input of accented/special characters. The VNC protocol has now been extended to allow the hardware keycodes to be passed directly from the VNC client to the guest OS without any intermediate translation step. This should allow the guest OS complete control over the keyboard layout mapping, without a need for any special settings on the host.

The final piece of work was to increase the guest desktop resolution. The real Cirrus video card that QEMU emulates would never have done more than 800x600, but there are tricks that can be done in a virtual world. Thus a simple change to the Xorg cirrus driver allows it to detect that it is using a Cirrus card emulated by QEMU and increase the guest desktop resolution to 1024x768. Still not great by today's standards, but better than before. Longer term plans involve replacing the cirrus driver in QEMU with something more virtualization friendly.

4. Also, as people should note, there has been a lot of work done surrounding KVM and getting that well integrated into Fedora. How has that work been going, and has anything significant been done in that area in this release?

Fedora was the first major Linux distribution to integrate KVM back in the Fedora 7 release. It became the default virtualization technology in Fedora 9, when it became clear we could no longer maintain the separate Xen host kernel until it was merged in the upstream Linux kernel. The great benefit of KVM from an distro integration point of view, is that it is there by default in all new Linux kernels. All that was required in Fedora was to turn on the module build and make sure the modules are always loaded when compatible CPUs are found. libvirt and virt-manager have also both supported KVM since it was first added to Fedora. Thus there hasn't been a need for much additional integration work for KVM. The focus has simply been on improving features available to KVM users via libvirt and virt-manager.

5. Glauber Costa has also done significant work merging KVM and QEMU. Can you explain to us what QEMU is, and why the choice was made to merge it with QEMU? How that is of benefit to the user base?

Earlier Fedora releases have suffered from the divergence of QEMU and KVM code bases. Upstream QEMU has had releases almost 1 year apart, while KVM has been releasing at least once a month, if not more, using snapshots of the QEMU source repository. Thus the features available in QEMU were far behind those available in KVM even though they both shared the same fundamental code base and upstream development stream. It also doubled the work package maintainers had to do for security and bug fixes.

Since Fedora 10 though, the upstream QEMU community has accelerated its release schedule significantly and many of the KVM features have been merged back into the main QEMU code base. Thus we judged that the time was right to attempt to ship a single package containing both QEMU and KVM built from a single code base. For users this means that parity of features between QEMU and KVM, while the reduced burden on our Fedora package maintainers, ensures more timely security and bug fixes. Glauber also took the opportunity to split out all the virtual BIOS files and ROMs from QEMU into separate packages and ensure all are fully built from source using appropriate upstream source releases.

6. Virtualization and security are discussed hand in hand these days, and as the ability to create and use virtualized machines expands there are many security risks involved. Can you speak a bit to the work that was done to improve security both at the kernel and user levels?

In each Fedora release we try to make at least one significant step forward in the security of our virtualization technology. In Fedora 8, libvirt gained support for secure remote management using TLS for encryption and x509 client certificates for authentication, while GTK-VNC, QEMU, KVM and Xen were also all extended to add a VNC extension for TLS encryption providing a secure remote desktop. In Fedora 9 libvirt was further extended to support SASL enabling secure remote management with Kerberos for authentication and PolicyKit for local desktop authentication. Fedora 9 and 10 also increased use of SELinux to protect the host operating system from a compromised or malicious QEMU/KVM process.

The latter still did not provide any protection between guests, so one compromised QEMU process would still potentially be able to compromise another on the same host. Thus James Morris started work on a project known as sVirt, the first results of which are appearing in Fedora 11. The focus has been to provide isolation between guests running on a single host. libvirt directly integrates with SELinux to ensure every QEMU process it launches runs within a dedicated security context, only able to access its own assigned disk images. This protection is enabled by default on all Fedora 11 hosts using libvirt for management. As well as the security benefits, the end user experiance is improved because libvirt will automatically manage SELinux labelling for all guest disks, eliminating a major source of bug reports from previous Fedora releases.

7. These features have all evolved over time in previous Fedora releases and Fedora, as a distribution, has always been a leader in the virtualization realm. Let's talk a bit now about the actual process of developing these features. How many of the improvements and enhancements to virtualization have come about as a direct result of the work done previously? Also, what does the future look like?

Virtualization technology in Fedora is reaping the benefit of very active upstream projects and the significant developer resources of Red Hat's Virtualization Engineering team. The combination of these provide great opportunities for new features to have their debut in Fedora releases.

The ideas for new features come from many sources, some from Fedora end-user experiences and consequent bug reports, some magically arrive on cue from upstream projects, while others are things that look to be important for future RHEL releases. With the PCI device passthrough feature in F11, the core support was all already done by the upstream KVM community. This is a important feature for future RHEL, so Red Hat put resources into a F11 feature to add support to libvirt for PCI passthrough with KVM and Xen and then expose this in virt-manager.

The feature aiming to improve the guest desktop interaction was a result of the persistent stream of bug reports from Fedora users. We had been considering ways to address this over course of several Fedora releases, but it was not until Fedora 11 that all the pieces of the solution finally came together from the various upstream projects.

The security improvements in virtualization have a different origin. Very few end users ever file explicit bug reports asking for the addition of more authentication / encryption features or to use more SELinux. If anything users ask for ability to more easily turn off existing security features. This is a case where the user is not always right. They do want more security, but they just don't know it yet!

As a developer it is necessary to be very proactive with security improvements. This can be particularly challenging work because the solutions often involve working across multiple upstream communities.

Take the VNC SASL authentication feature in Fedora 11 as an example. The first step was to write a specification for a new VNC security extension, have it reviewed and get a code for it allocated by RealVNC. Work on QEMU was required to implement the server side. Work on GTK-VNC was needed for client side. For management tools, work on libvirt was required to get the new security type enabled for guests it launches and finally virt-manager was extended such that it knows how to login. That's five different projects involved for one feature. This is only practical by having a close working relationship with all the upstream communities and carefully coordinating the work there so it all arrives in time for the next Fedora release.

For the future we're happy that libvirt gained support for managing VirtualBox recently and likely to soon have a driver for the Open Nebular cloud management project. Expect more advancements in sVirt, allowing for tighter controls on what a virtual machine can do, for example, ability to restrict network access of guests. libvirt will also gain the ability to manage host network configuration in Fedora 12, removing the need to manually configure bridge devices. Container based virt may make a more formal appearance in Fedora 12 as the native Linux container (LXC) support improves in the kernel and libvirt. The overhaul of the virt-manager user interface also continues.

8. Working on virtualization must be awfully time consuming and involved. Do you enjoy it? What do you do to get away from the pressures of hacking?

Working on open source virtualization technology is a great experience because it is a really interesting and challenging field, having plenty of talented developers to work with and learn from. There is plenty of work still to be done at all levels of the stack from kernel/hypervisor right through to end user applications and not nearly enough time to do it all. I'm fortunate to be able to spread my work between upstream projects, the Fedora community and RHEL releases and maintenance.

As for free time? What free time? :-) I try to find time for a photography, with 4 out of my 5 cameras still using film, rather than digital.

The Sound of Fedora 11

An Interview on Fedora 11's enhanced Audio Control with Lennart Poettering

Where would we be without sound? It's the most primitive of communication methods, and yet it has spawned so much technology around it. Whether you're a musician, a DJ, riding a bus to work, or even just stuck in a cubicle listening to the radio somewhere, sound has become an integral part of your daily experiences. When Fedora 11 lands, along with it will land a number of enhancements to the sound subsystem, including unified volume control, per stream and per device monitoring, and proper Bluetooth audio support. I recently caught up with Lennart Poettering, Red Hat Desktop Team Engineer and resident audio guru. Here's what he had to say about the upcoming improvements and what the future holds:

1. Please introduce yourself and give us a brief intro to how you started working on the upcoming audio improvement in F11.

I am Lennart Poettering and have been working for Red Hat in the Desktop Group for two years now this month. I live in Berlin, Germany.

PA has been part of Fedora since F8. Since then we used to ship two volume control appications: the GNOME volume control and a PA (Pulse Audio) specific tool (pavucontrol). The latter was mostly a showcase what can be done with PA and I wrote it mostly as a demo, not because I thought it was any good as an UI.

Of course having these two volume control UIs in Fedora was a situation that badly needed fixing. Especially since both UIs exposed too many unnecessary options: the GNOME volume control exposed a lot of low-level hardware-specific features that only a tiny minority of people actually really understood, and the PA volume control exposed a lot of low-level software features that a slightly larger minority of people only actually really understood.

Now during the last year we reached a point were the feature set of PA for volume controls became very complete (with such things as arbitrary meta data on every stream/device, per-stream and per-device monitoring, hardware volume range extension, "flat" volumes and lots of other stuff) and Jon McCann with help from Bastien Nocera finally took up the work to
fix the UI situation.

They basically designed the new UI from scratch with input from usability experts. It implements many of the features the old pavucontrol tool did, but in a much nicer, streamlined way. Also it integrates sound theme/event sound control with general audio configuraton and volume control in a single UI tool.

2. Can you give us some background on the upcoming changes to the audio subsystem in the Fedora 11 Release?

If you want to know more about the Volume Control, I'd just refer to the Feature page:

https://fedoraproject.org/wiki/Features/VolumeControl

We moved PA 0.9.15 into F11, a nice overview over the new features you can find here:

http://0pointer.de/blog/projects/oh-nine-fifteen.html

However that overview is a bit out-of-date. There are quite a few additional features that went into 0.9.15, most prominently full Bluetooth Audio support: Together with Bastien Nocera and the BlueZ guys I worked to make Bluetooth audio easily accessible -- the bluetooth applet now exposes an easy dialog that allows you to pair and activate a bluetooth headset. After that is done it will automatically appear in PulseAudio. If you need to reactivate it later, you can do that with a simple click in the applet menu. It works surprisingly well. It even works fine for lip-sync video. Which is kind of magic, given that Bluetooth Audio doesn't actually offer any timing interfaces, so syncing up audio with video is not really possible. I spent a lot of time to make sure it does work nonetheless, and it seems to work on the majority of headphones although I cannot say for sure if it does for all of them.

3. Where did the ideas to change all this stuff come from? Didn't audio always work in Fedora?

Depends what you mean by 'work'. Sure, basic audio output worked. But in many ways what we had on Linux was not comparable to what MacOS or Windows supported. And it still isn't in many ways. However in other ways we have now surpassed those competitors.

A lot of the changes we introduced with PA are not directly visible to the user. For example the so called 'glitch-free' logic in PA is very important for a modern audio stack, however the normal user will never notice it -- except maybe because when we introduced it initially a lot of driver bugs got exposed that people were not aware of before because that driver functionality (usually timing related) was not really depended on by any application. In fact even now many of the older drivers expose broken timing that makes usage with PA not as much fun as it could be.

A more detailed explanation of this 'glitch-free' logic you may find here:

http://0pointer.de/blog/projects/pulse-glitch-free.html

Both Windows Vista and MacOS X have similar g-f logic in their audio stacks, however with PA we brought it to the next step. For example, we implemented this logic in a zero-copy fashion and with arbitrary sample types. This allows us to pass PCM data through our pipelines without ever having to copy/convert it unless we really have to.

So yes, as you might have noticed I spend a lot of time to get low-level internals right. And I like to speak about it, even though most people are not aware of all those technical details and how awesome this all is. ;-) That said, this stuff isn't perfect yet and could need more improvements.

But it's not all just in the low-level details. Also on higher levels we got inspired by how our competitors do things. For example the new "flat" volume logic was pioneered in Vista, and we have now adopted a similar logic in PA. It's a great way to reduce the complexities of volume control by 'merging' a few of the sliders in the pipeline. It thus solves the "So which slider is now causing my volume to be too low?" a bit. But also here, there's more work to be done.

It's not all just getting inspired by our competitors. There are a lot of genuinely new features in PA that none of them have (at least to my knowledge). For example, in PA we have 'spatial' event sounds. I.e. if an event sound sound is triggered by a mouse click/dialog at the left side of the screen the sound is generated more from the left speakers, and similar for the right side. This is of course mostly a toy. But I think a useful one ;-) .

Listing all the fancy features PA has would certainly be a bit too much for this interview. So I'll leave it with this... ;-)

Generally, we get inspiration from everywhere. And sure, as long as the most basic music playback was enough for you audio did always work in Fedora. But OTOH, when we started with the integration of all of these new audio features into Fedora two years ago the audio stack was still at a point of what was modern in the 90's. With the new features of the new volume control and PA we are working on bringing Linux audio to what is modern today.

4. Can you also give us a comparison of our new audio framework in reference to other audio frameworks and audio subsystem models that are out there?

There are many frameworks out there. On Free Software systems PA doesn't really have any competitor. Some people think that JACK is one, but it actually is not. JACK is clearly focussed on audio production and not very useful on the desktop otherwise. For example, it is strictly designed to provide very low-latency at the price of power consumption. This is the right thing to do for audio production but not on the general desktop. Logic like 'glitch-free' (see above) makes a lot of sense for the usual desktop audio since it allows flexible adjusting of the latency to what is needed. If used properly it can be used to decrease the interrupt rate to 1/s, while still allowing instant reaction to user input. Since most PCs these days are laptops theses kind of power consumption related features are very important.

One of the current weaker points of Audio on Linux is that we have this clear separation of JACK for audio production and PA for desktop/embedded. Other operating systems have managed to make this a bit smoother by having a single stack for both. This however actually has both advantages and disadvantages.

To improve the situation for now we focussed on making PA and JACK cooperate better. In F11 when JACK needs low-level access to an audio device it will tell PA so and PA will comply and release the device.

This should make switching between the two sound systems easier though of course this is no perfect solution. Given the lack of manpower further integration is unlikely to happen anytime soon -- though both the JACK guys and I seem not generally opposed to something like that.

Now, if you compare our audio stacks with those of the big other operating systems (Windows and MacOSX), then besides the fact that they usually integrate desktop audio and audio production better than we do (as mentioned) there are many things we are better in and many they are better in. We certainly have more flexibility: i.e. depending on your application you can access audio on a lot of different levels: you can access ALSA directly if you need very low-level control, or via PA for desktop level control. You have APIs like GStreamer for media streaming and so on.

This flexibility however translates to more complexity in many ways, and a hodgepodge of API styles. (OTOH Apple's CoreAudio actually isn't as streamlined as many MacOS proponents like us to think.) The documentation for our APIs is usually much worse then theirs. We really need some improvements in that area. Featurewise, PA usually has better networking related features then those counterparts. But there's a lot of features they have right now we lack.

Other Unixes, such as FreeBSD and OpenSolaris are still stuck with OSS (Open Sound System) audio. In F11 we finally switched OSS off by default (though you can still reenable it via some minor hackery). OSS was the predecessor of ALSA. Thankfully it is now fully obsolete on Linux. OSS is mostly a design from the early nineties. It has received only minor updating since then. It is no way comparable to what we now have on Linux or even what MacOS or Windows provide. (Although is has some very vocal fans which like to write me hate mails because I say things like this)

5. This work all started in earlier releases dating all the way to even Fedora 8, if I am correct. How has all this stuff progressed and evolved from then? What was done in previous releases that enabled building upon for this release?

Fedora 8 was the first release where we integrated PA. In Fedora 9 we stabilized PA support. In F10 we integrated the 'glitch-free' logic which turned out to be quite a bumpy ride given that it exposed a lot of timing related driver bugs. In F11 g-f has now been made more robust and most of the more modern audio drivers should now be fixed. Also we have now started to push PA support more into the UI, like with this new volume control.

6. What are the plans for the future, if any, in this particular space in the distro?

I am working on multiple things for F12. Firstly there will be a couple of more low-level changes to PA. The core will be made more threaded. Right now, we run most things in one 'main' thread and do low-level audio I/O in one thread for each audio card. My plan for F12 is to split that one 'main' thread up into as many threads as possible. This should make PA more robust for a couple of operations, and make latencies more reliable.

Then, I am working on considerably beefing up PA's usage of the low-level hardware volume controls. For example, many cards have seperate low-level volume sliders for "Speaker", "Master", "PCM" (and more) that are in the line from the PCM data we stream to the speakers. PA currently exposes only one of those sliders (usually "Master"). My plan is to 'multiply' those sliders and create a single 'product' virtual slider from them that has a better granularity and a larger range. This rework will also introduce input/output switching and probably more.

What has already landed in PA's git repository is support for UPnP A/V. When used in conjunction with Zeeshan Ali's Rygel UPnP MediaServer implementation this allows streaming any application's audio to a any UPnP MediaRenderer (including PS3/Xboxes and all those 'Internet Radio' devices). This is actually pretty neat. Later on we hope to make PA a Media Renderer as as well as a MediaServer. This nicely compliments our current Apple RAOP support.

And there's a lot of other things planned. We'll see how much of that will be ready for F12. I don't like to talk too much about upcoming features and planned code if I don't have anything to show yet, so I'll leave it at this.

And then there's always a little project of mine that is called 'libsydney' that is intended to be a portable, modern and friendly PCM API. During the last months I focussed more on PA itself though.

7. Do you feel that work like this helps enhance the desktop experience on Linux in general and strengthens the cause of the Linux Desktop, or is it more all in day's work?

I think that PA is the way forward for audio on the Linux desktop. It may have its deficiencies -- but everything has. We still have some way to go, but I believe that a modern audio layer is really important for the Linux Desktop to succeed.

And no, it doesn't feel at all in a day's work. It always is a great feeling to see how PA got incorporated into so many distributions and how it is now used by so many people. I am pretty sure that only if you hack on Linux software you get this in this ways.

8. Speaking of all in a days work, what are things do you usually work on? What do you most enjoy doing outside of work.

Red Hat basically hired me to help improving audio on Linux. So that's what I am doing during work.

Outside of work spend my time with photopgraphy. And I am trying my best to travel to interesting places as much as I can and my time off allows.

Thank you Lennart for an excellent interview, ideas and insight. We look forward to hearing more from you. Get it--hearing more, he works on sound, okay I give up.

Fedora 11 Podcast Series #4 - KMS with Adam Jackson a.k.a. Ajax

For the fourth podcast in our Fedora 11 podcast series, we turn to the magic that is our display system. One of the coolest new features in Fedora 11 is the ability to do kernel based mode setting for the display. Kernel mode setting allows the kernel to set certain parameters for the display and moves this functionality out of the X server itself and out of user space. This enables cool things such as quicker graphical boot up and fancier eye candy. For more information I caught up with Fedora X and diaplay guru Adam Jackson. Adam is a lifer on the X scene and knows more about displays than you, I and probably he himself want to know.

Kernel Mode Setting with Adam Jackson

In the interview, Adam talks about the hidden underbelly of Linux and X graphics and displays and how previous version of Fedora may, or may not have been able to trigger seizures. Adam also expands the possible inclusion of a kernel crash screen of death (yes it comes with flaming eyes), how collaborating with other distros and upstreams has helped him achieve great things and how that helps others, and finally, about the upcoming Boston area concert calendar.

Fedora 11 Podcast Series #3 - General Overview of F11 with Tom 'Spot' Callaway

Continuing on in our series of Fedora 11 podcasts, we present an interview of the series with Tom 'Spot' Callaway. In case you don't know Spot, he's been making Fedora happen since before Fedora was called Fedora. Spot is a Red Hat Engineer, the Fedora Engineering Manager, and of course an active and knowledgeable community member. With keen insights and an eagle-eye view of the Fedora release process, the community, and our history and roadmap, you can be sure that any chat with Spot is worth your while.

Fedora 11 General Overview and Insights with Tom Spot Callaway

In the interview, Spot covers much ground, with everything from features in the upcoming release such as 20 Second Startup and Kernel Mode Setting to the future Fedora artists movement. Spot also talks about the importance and benefit of Fedora's upstream oriented developer process, the recent enhancements to Fedora's QA process, and the addition of members to the Fedora QA team. Finally Spot takes a nostalgic trip down Memory Lane, with a discussion of the long history behind Fedora, what he thinks Fedora as a community has to offer contributors, and why Fedora is the very best place to be.

The Countdown to Fedora 11 Begins!

Fedora 11 is less than two weeks away. The excitement is in the air and we all can't wait to see the product of more than a few long months of hard work. It's prime time to start talking about what users can expect to see, highlight new features and describe some of the enhancements that we can all look forward too. As part of a series of podcast and print interviews, Today, I would like to present the first podcast in the Fedora 11 Podcast series, an interview with long time Fedora contributor and Fedora Release Engineer Jesse Keating. The audio can be found here:

"Fedora 11 General Overview with Fedora Release Engineer Jesse Keating"

In the interview, Jesse talks to us about the achievement milestone of putting together 11 releases, the process of planning and putting together a Fedora release, how it was done for F11 and also some of the tools, which he helped create which are used to put together the Fedora distribution. He talks about Pungi and Revisor which are tools used to compose the Fedora tree and create a custom remix or re-spin, respectively. He also talks about some of the changes which have taken place under the hood to enable Fedora's new faster and improved boot up. Jesse takes us on a whirlwind tour of some of the greatest enhancements we can look forward to in F11, including changes to PackageKit and a new upstream version of RPM, the new default ext4 filesystem, enhanced fingerprint support for authentication and what we can look forward to in the future releases of Fedora.

The Full Fedora 11 Feature list can be found at http://fedoraproject.org/wiki/Releases/11/FeatureList and you can look forward to more in depth coverage of some of those features and of the upcoming release in the days to come. Fedora 11 is sure to prove a highly innovative and technologically advanced release.

Fedora 11. Get ready. There's reason to be excited!

Duke Nukem Forever. Never?

In a rather sad bit of news I was just pointed at this: Report: Duke Nukem Developer Shuts Down.

You heard it right, 3D Realms is going, going, gone. This is very troubling as I have friends who have been checking the 3D Realms website every day for the last 10 years waiting on any little tidbit of information. Yes, I am aware that it is sad that I just said that, but its the truth.

I am unsure of exactly what IP agreements are in place regarding everything surrounding the game, whatever of it does exist. Regardless, I will use this is an opportunity to call on 3D Realms to open up the source code to the game and let the people work on finishing it. They can retain the rights and all that good stuff, but for heaven's sake, don't let the Duke die!

As the Duke would say, "It's time to kick ass and chew bubble gum, and 3D Realms is all out of gum."

Do it. Do it.