I’d suggest sewing the velcro together vs stapling, especially if you have cats that are far too curious about staples.

[jbowes@workstation ~]$  history | awk ‘{a[$2]++ } END{for(i in a){print a[i] ” ” i}}’|sort -rn|head -n 12
163 ls
156 cd
115 svn
76 vim
70 screen
55 fg
47 exit
35 sudo
30 git
21 yasql

Seen on Adrian’s and Mike’s blogs.

Love,

James

So far I have completed 4 out of 179 problems, which makes me 2% genius, according to the site.

mdehaan points out a wonderful section wherein the authors relate Java programming to a plumber in a hardware store, finding pieces and putting them together to solve a problem, rather than their unmentioned alternative (maybe an artist molding clay?)

If this is true, then we, the software industry and software engineering fields, are done. We have found the holy grail: true modularity and reusable software components. Drop whatever language you’re using and switch to Java.

He may have been sarcastic. Maybe.

First, offline upgrades will always be required for some cases. There’s always going to be some cruft we need to drop, and can’t do it on a live system.

Second, allowing upgrades from release X to X+2, etc is too risky and would need more QA than I think we’d be willing to commit. Likewise for rawhide to stable, or stable to rawhide. These all should be possible for the intrepid, but not defaults options.

A use case for upgrades

Franky Fedora is a Fedora user. He uses a default install, and is not familiar with the command line. Whenever the update applet appears at the top right of his screen, he launches it and updates his system. One day, instead of the regular update icon, a different one appears with a popup message “A new version of Fedora is available! please click to upgrade.”

1. Franky double clicks on the icon.
2. Franky is presented with information about the upgrade, including release notes and an advisory to back up any important data before continuing, as well as a choice to continue or cancel.
3. Franky selects continue, and is presented with a list of tasks, as they complete, they are checked off. The list looks like:
   • Updating current release
   • Downloading software for upgrade
   • Preparing system for upgrade
   • Upgrading system
4. As time progresses, the items on the list are checked off. Meanwhile, Franky is free to do other tasks.
5. Once all items on the list are checked off, Franky is presented with a message telling him that his upgrade is complete, and advised to reboot his system. He is given the choice to reboot now, or not to reboot if he wishes to complete other tasks.
6. Frankly chooses to reboot. His system restarts, and he is presented with the next Fedora release, and all of its wonderful new artwork.

Extension Points:

2a. Franky selects cancel, and is returned to his regular desktop.

3a. Franky’s system requires a new filesystem, so he is presented with the following tasks instead:

• Updating current release.
• Downloading software for upgrade.
• Rebooting system info upgrader.

1. As the items on the list are checked off, Franky is free to do what he wishes.
2. When the final item is checked off, Franky is presented with a message telling him his system must be restarted to continue the upgrade. He can select to reboot now, or to do so on his own later.
3. Franky chooses to reboot now.
4. His system restarts, and runs the Anaconda installer.
5. Once complete, Franky’s machine reboots into the new Fedora release.

5a. Franky chooses to reboot later, and is returned to his regular desktop.

1. Later he reboots, and moves on to step 6.

Proposed implementation details

• An upgrades metadata file added to the main repository metadata. This file will contain a pointer to the new Fedora release, as well as some caveats for upgrading. For instance, that the i386 version of dbus must be removed before upgrading.
• The upgrades file will specify whether a live or offline upgrade should be done.
• The caveats will run during the ‘Preparing system for upgrade’ step.
• The updating current release step is just a ‘yum update’ after it is completed, the upgrade tool shall restart, if it has been updated during this process.
• The caveats metadata will be updated over time if any new issues arise.

Interaction between the upgrades metadata and other repos may get hairy. How does the system know what do to when you are running updates versus updates-testing? Perhaps each repo should have upgrades metadata.

This is all an extension to the F9 PreUpgrade feature. Getting the Anaconda reboot working is a great first step. Once that’s done, we can move on to the optional live upgrade, a command line interface, etc.

Comments/flames appreciated.

I’m quite certain this is the most worthwhile thing I’ve done this week.

Thank you, developers of yore. You’ve made things oh so much clearer to this lowly maintenance programmer.