Don't say I never gave you nothing.

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:

1. I've told nautilus to not conrol the desktop
2. I've added a transparent panel to the right side of the screen
3. I've moved the launchers from the top panel to the top of the right panel
4. 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:

1. 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.
2. 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.
3. Only one panel
• Only one panel, period, along the top stuck to the top-right corner, resizeable on the left.
4. 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:

5. 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.
6. 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.
7. 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.

Comments and criticism welcome.

Every second is a new year; a chance for new opportunities and new successes.

And just so that this post doesn't become completely touchy-feely, here you go.

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.

Fedora 10 on the XO

blah blah normal Fedora 10 on the XO on a USB drive. Here's how:

1. Find a machine that can boot USB devices and that you can install Fedora with.
2. Get a drive big enough. In my case it's a 40GB.
3. Install Fedora 10 i386 normally, with these options:
• Separate /boot as the first primary partition
• Install grub to /sdX1, not the MBR
4. Boot off the USB drive.
5. Install the i586 kernel. Use yum shell if you need to remove the i686 kernel at the same time:
• # yum shell
• > remove kernel.i686
• > install kernel.i586
• > run
6. Put this xorg.conf in /etc/X11.
7. Create the /boot/security directory and put your developer key in it. (optional)
8. Create the /boot/boot directory and put this olpc.fth in it.
9. Open /boot/grub/grub.conf and /boot/boot/olpc.fth and do the following:
• Replace $args at the bottom of olpc.fth with the i586 kernel arguments from grub.conf.
• Replace vmlinuz0 and initrd0.img with the filenames of the kernel and the initrd respectively.

You may be able to skip the kernel-swapping step by passing i586 at the install boot prompt. I did not try this.

Python 2.6

Preparations are now underway to get Python 2.6 into Fedora. Watch the skies in the next few days.

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

1. 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.
2. 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.