What is SPICE? - It stands for "Simple Protocol for Independent Computing Environments". What does that mean exactly? SPICE is a remote display protocol designed specifically for use with the Linux kernel's built-in virtualization hypervisor KVM. SPICE is similar to terminal services but rather than multiple users sharing a single, remote physical machine, SPICE allows you to graphically connect to and use a local or a remote KVM virtual machine.
For those who want to just watch a video, here it is. Please note that I kept bumping the tripod by accident and autofocus can be annoying in some spots... and it isn't the highest quality... BUT it does give you a good idea of how well SPICE works.
If you can't see it, your browser probably doesn't support the WEBM video format yet. Right-click on any of the links below (webm and ogv) and download. Then play the file you downloaded in a recent version of VLC.
I like to write reviews. I have written quite a few of them over the years... even back in my Atari days for a few print magazines. I mention this because while I'd like to write a review of the Fedora 14 release I feel like too much of an insider to be objective and I'd have trouble being as critical as a non-biased observer would be.
Yesterday I ran across a link on Fedora Planet for a video review on the Linux Action Show. I have watched a few of the LAS episodes before but am not a regular viewer... but since the topic of the episode was listed as "Fedora 14 Review" I decided to give it a viewing. About 33 minutes into it they get to the Fedora review... although it is hard for me to call it a review. It is unfortunate but they started with the Fedora 14 Release Announcement and used that as a basis for their review. Historically release announcements are very brief documents that give only spartan details but include links to other sources of more complete information, like the Fedora 14 Release Notes for example. Given the fact that the release announcement only states two new features for desktop users (libjpeg-turbo and Spice) it seems they assumed that was all there was to the release, given the fact that their main focus is desktop usage. As a result they spent most of their review time in ridicule mode... divided in two... with both an attempt at humor and at a "wake up call" style denouncement of everything Fedora. They even included an original conspiracy theory.
I think everyone who knows me understands I have a pretty healthy sense of humor that can sometimes go to the dark side... but I found almost nothing about their show funny. I'm guessing some people find their show hilarious... but me... and this episode... I'd say frustration was my reaction.
I did get on the Linux Action Show IRC channel (the only form of contact on their contact page that I use) for a few minutes and discuss with someone (probably not them) that it was unfortunate that Bryan and Chris had chosen the very brief release announcement as the authoritative source of "what's new in Fedora 14" rather than the release notes... but I do concede that the release announcement could have been much better than it was.
I've been following the development and building my MontanaLinux remix every so often, usually after a bunch of updates. All in all, I'm pretty impressed with the release.
If you know where to find the RC1 release, which is freely available, that is the final release (to the best of my knowledge). So if you want Fedora 14 early, download that. I did, although I'm mainly using my remix.
Since the Fedora Remix build process on Fedora 13 broke some time ago after some package upgrades and they were dragging their feet about fixing it, I switched to Fedora 14 devel for my MontanaLinux Remix effort. It sure is fun. Luckily the RPM Fusion folks have devel packages for Fedora 14 so I'm not missing anything.
The only problem I've run into is with adding the Google Chrome Browser to my package set. For some reason, if I install Google Chrome as part of the build, I run into a issue with a failure to umount a loopback interface that causes the building of the iso to fail. Removing Google Chrome from the package list makes the issue go away. I guess that's actually a good thing because I'm not sure how Google would feel with me pre-installing their browser and distributing it. If I had picked Chromium, I'm sure there wouldn't be a distribution issue.
Anyway, the switch to Fedora 14 devel seems to have worked out quite well and it is actually in pretty good shape. There is one minor bug that I find annoying and hope they get fixed before the final release. Also the devel kernel has a lot of debugging options turned on that makes it a bit slower than usual, and I do have an occasional issue with sound after resuming from sleep on my Acer netbook... but I'm guessing that will get fixed in the release kernel. The switch has gotten me more involved with testing and reporting bugs and that is good.
If anyone wants to give it a try, email me and I'll give you a URL to download the .iso. 32-bit and 64-bit versions are available.
I've been building a Fedora Remix for some time now. If I remember correctly I started around Fedora 9 and have continued to build them with each new release. I'm on Fedora 13 now. I usually rebuild the remix every time a new set of updates comes out. So far I had rebuilt the i686 and the x86_64 remix 46 times each... and then someone reported some problems with the last couple of builds. I didn't notice because I had been on vacation and was doing the rebuilds remotely without testing the final product. I figured if it built ok, it was probably ok... because I hadn't previously had any problems with any builds.
I wrote a rather long response to a posting I saw on Fedora Planet entitled, "Death of the Year of the Linux Desktop". I'm sharing it here as well.
- - - -
The desktop is dead? Some disagree. See this very compressed video on the "Death of the Desktop":
What makes someone a winner and what makes someone a loser? Linux on the desktop has tens of millions of users. While that might not be double-digit market share it is still a significant number of users. Anyone who looks at those numbers and calls them losing must have thought the game was winnable to begin with. It wasn't. FOSS does not spend hundreds of millions on advertising and billions on under-the-table deals with hardware makers... FOSS simply does not operate on the same playing field. The free hand of the market happens to be attached to a twisted arm.
In reality there aren't any winners and losers because it isn't a race. While those who are in it for money have certain ways to measure success, in FOSS you just make the best software you can and hope users will appreciate it. Of course the squeaky wheels always make the most noise and there are lots of complainers out there (see discussions on KDE 3.x vs. 4.x as an example) but that doesn't mean that vast majority of us FOSS users aren't very happy.
Recently a GNOME survey (aka the Neary report) came out that showed who contributes to GNOME and at what levels. Not so oddly enough the results of it turned out similarly to periodic Linux kernel surveys done by LWN and Greg KH. The results being that Red Hat is the top named contributor.
It just so happens that Canonical (the sponsor of Ubuntu) typically does not fair so well on such surveys and as a result they are often criticized for their perceived lack of upstream contributions.
From attending Jesse Keating's talk about the upcoming features in Fedora 13 I learned that the rawhide repository has been split in an effort to provide a more stable build environment for Fedora releases. I also learned that it is a good idea to disable the updates-testing repo to help avoid potential breakage. Jesse also said that at some point during the upgrade cycle that the Beta will turn into the release version. With the new information, I decided that it wasn't too early build my MontanaLinux Fedora remix.
I had installed the Beta on a couple of physical and virtual machines and was fairly impressed with it so I decided to go ahead with the remix effort. First I would have to find all of the repository URLs to pull the packages from. That wasn't too difficult... just look at the files in /etc/yum.repos.d/ on a Fedora 13 Beta system.
To save on bandwidth over many builds I decided to rsync the entire development tree down so I would have a local copy. The i386 devel tree is about 19GB with 16,787 packages. The x86_64 devel tree is 21GB with 20,811 packages. I also have to rsync every day or two to keep up with package updates.
The RPM Fusion folks already have packages for Fedora 13 and the existing Adobe packages work fine on the Fedora 13 Beta as well so the this remix will be pretty close my previous remixes.
I am building from within a Fedora 13 Beta KVM virtual machine. I composed the first build yesterday and installed it on my netbook last night. I have noticed a few glitches in my initial package selection. For example I installed sugar* and that brought all of the sugar packages including sugar-logos which is a boot-time Plymouth animation. As a result, booting my netbook for the first time after install showed the Sugar animation which I wasn't expecting at all. Also the number of packages I had was right on the edge of 2GB and I wanted to insure that it would continue to fit on a 2GB USB thumbdrive... so I decided to update the package set. I decided to remove sugar completely because that would free up some room and get rid of unwanted boot animation.
I'm doing a second compose right now. We'll see how that turns out.
What's under the hat? A sneak peek at Fedora 13 by Jesse Keating.
I recently started using a tool that I find very handy. It is named func and it is a remote api for management, configuration, and monitoring of systems. What does that mean exactly? I'll get into that but first a little background.
In my day job I manage a number of Linux systems. Some are servers and more are desktop machines in labs used by students. All of the lab machines are triple-boot (Windows XP Pro, CentOS 5.4, and Fedora 12). Fedora has a lot of updates... and it is hard to keep up with them. Typically I have to ssh into each machine to work on it but most of what I do is the same thing over and over again. Wouldn't it be nice to be able to manage multiple machines at once with one command line? That is what func does for you. func allows you to manage remote machines with one command line in parallel.
func was written by Fedora developers mainly to help them manage the server infrastructure that makes up the Fedora distribution's online public servers and build systems. They have an active mailing list that you are encouraged to participate in if you are interested in asking questions and helping to shape the future development of func.
func is written in Python and comes with a number of modules that are custom built for certain tasks. If there is an existing module for your task(s), use the existing module. If not, you can use the command module which basically allows you to run whatever command(s) you want on your remote machines.