I've had time to review more of the FUDCon 11 videos, specifically the KVM, Moksha, and Desktop videos. The KVM and Moksha videos pretty much only had me saying "neat", not that I thought they were boring, just that I saw nothing to comment further on; I think both are great ideas and I'm sure that both are only at the very beginning of their potential. This then leaves the Desktop video. But I'd like to digress before I give my thoughts about it.

I first heard of Linux through a classmate, via RHL 5.1. I dabbled with it through 7.2, then drifted away. I'm not sure what caused the drift. I think it was games. Anyway, I used Windows up until Windows 2000, when I decided to take a look at this new-fangled thing called "Fedora". I set up my system as dual-boot between Windows 2000 and Fedora Core 2. I didn't boot it into FC2 very much, simply because I already had Windows 2000 set up how I liked it, and to be completely honest, Windows 2000 wasn't terribly bad. In fact, I found that it suited my needs as a desktop well. The only thing I missed was multiple workspaces.

But blah blah blah, enough of that. How does that relate to the Desktop video? Long story short, I saw the GNOME 3.0 demo, and I don't get it. How does any of that help me get things done? Why should I worry about managing the number of workspaces I have? I'm not going to say anything about the launcher application selection since I'm sure it will go through one or more revisions before they come up with a sane scheme.

"Okay big talker, how do you think it should be done?" Well, we'll get to that in a second. First I want to show you an experiment that I'm undertaking, working within the confines of the existing technology:

As you can see, it's very similar to the GNOME default with a few significant changes:

I've told nautilus to not conrol the desktop

I've added a transparent panel to the right side of the screen

I've moved the launchers from the top panel to the top of the right panel

I've added the trash and drive mounter applets to the bottom of the right panel

This mostly works, except for a few issues with (auto)mounting, and with the clock applet not playing nice with the right panel.

What I envision though, goes even further:

A number of changes are in place here. The visible ones:

No more desktop

No more files, media, or icons on the desktop. Use a file manager window to get at them. Media and trash are now stuck to the right side of the display, extending up.

No more workspaces

Instead of a number of individual workspaces, there is only one solid desktop which is much larger than the display. The display need not snap to any boundary short of the actual edge of the desktop. A modifier is used in conjunction with the pointer in order to slide the display around the desktop.

Only one panel

Only one panel, period, along the top stuck to the top-right corner, resizeable on the left.

Detached menu and launchers, in their own space

Programs dragged from the menu can be dropped on the left hand side, which gives them their own launcher. Much like a panel, but transparent parts allow anything underneath them to be manipulated.

Of course, there are also a number of invisible differences as well:

No Minimize or Maximize functionality

Since there are no workspaces, neither option makes sense. Instead Lower (push this window to the bottom Z-level) and Fit (fill visible display) functionality will be used.

Applets on the panel will stick to a side

You will be able to rearrange applets as you like, but they will gravitate towards either the left or the right. If you need them separated from other applets, then... use a separator.

Moving the pointer past the edge of the display will not slide it

In this scheme the sides of the display are important, so you can't push the display just by moving to the edge.

So there you have it. I'm sure there's a few things I missed in there. As always, comments and criticism are welcome.

I just finished watching the XO/RPM FUDCon video, and here are my thoughts, in no particular order:

Packaging activities as rpms is a lost cause; there are almost none important enough to require root capabilities to install. Package known-good versions of Browse and Terminal with Sugar, and move on.

Activities are exactly like DVCS repos:

The master is the versions of the activity from upstream. 1.0, 1.1, 2.0, etc. All versions would be contained within it.

User-modified versions are branches, each based on a specific version; Kim's is a UI hack based on 1.0, while Miguel's adds additional transports and is based off of 1.1.

Branches are separate from the trunk; both the trunk and each of the branches can be moved around independently, and the branches depend on the trunk in order to function properly. It will be the job of rainbow or whatnot to reintegrate the activity so that it can be run.

The icon on the Activity view is the normal icon for the activity, and represents the latest version of the master. It can be right-clicked to either rebase the existing activity to a user branch (or the master as the case may be), or add another icon representing the user branch. User branches would be indicated with the homunculus of the creator as an emblem.

Activities can still be stored in a central place, perhaps mediated by an "Activity Manager" daemon or process.

Whew! I finally got Python 2.6 into Rawhide. I'd like to thank the following people for their invaluable help:

Jesse Keating

Toshio Kuratomi

Alex Lancaster

Panu Matilainen

Rex Dieter

And of course, every Fedora Contributor that maintains or uses a package in Fedora that uses Python in one fashion or another, since your kind assistance will be needed in order to complete the integration of this new version.

Python 2.6

I had originally agreed to give a presentation about packaging a part of the Fedora Classroom series. As time passed I realized 2 things:

There isn't enough bandwidth in IRC to deal with the intricacies of editing/completing spec files, and I don't believe making our gobby server open to the public would be a good idea.

I've already written a very goo (if incomplete) article that covers most of packaging.

So instead of talking about packaging, I'm going to be talking about packages. How to identify them, how to use them, and so on. The talk will be a little more disjoint due to the running around that needs to be done, but it's better than me just typing the article out in IRC.

So you'll still have to read the Building Packages Guide if you want to learn about packaging (and I urge you to read it), but I'll be more than happy to answer any questions you have about it during or after the session, with the exceptions of "why is it still a draft" and "when will you finish it" (because, and whenever :P ).

Step the First: Write an Application for Windows

Actually, applications. Lots of them. Use as many varied core Windows technologies as you can. COM, ActiveX, DirectX, you name it.

Step the Second: Gain Popularity

Get people to like and use your applications. Lots of people. People with money. People with power.

Step the Third: Keep an Eye on New Windows Technologies

And then promptly ignore them. .NET? Who cares. WPF? Passing fad. Force Microsoft to spend billions of dollars to keep your apps and their 20-year old API calls working. The building pile of legacy in their codebase will compound and eventually overwhelm them.