monline

(...) Modern Linux distro's, say Ubuntu (8.10) comes with a default PHP configuration of session.gc_probability = 0. This means that in general, session GC will never run(!). There is a unix cron job that runs every half hour and checks for old sessions to delete (see more at /etc/cron.d/php5) but this is done only if you're using the standard "files" as your session handler (check out the directive of session.save_handler on your machine to learn what php default sessions handler is but make sure to check that your application doesn't overwrite this), so for Drupal users using plain Debian/Ubuntu, stock LAMP packages and stock Drupal applications, this means that the PHP garbage collection, despite your best intentions, will also never run. (...)

A few additional links:

• How to add a new PPA source to your list of software repositories
• Firefox PPA
• Thunderbird PPA

One thing about APT pinning I've now learned for life is that you should always check the output of apt-cache policy. In various distributions and APT versions the pinning might behave a bit differently. Checking the output of apt-cache policy (note that there's no package name at the end of the command, thus it'll list your APT sources and their pinning values) reveals most probably the reason why your preferences file does not do whatever you wish it to do.

You can right-click any file in Nautilus (the default file manager of Ubuntu), select "Properties" and switch to the "Open With" tab to change a file type's association (ie. the programs that appear when you right-click a file and go to the "Open With" list ... and the program that will open on a double-click). However Ubuntu has no app for managing all file associations together in a single UI. Eg. what if you'd like to know what file types are associated with Gedit. No problem: all of your personalized file associations are stored in the file $HOME/.local/share/applications/mimeapps.list (as defined by the freedesktop standard). Of course a lot of the "active" associations are not in your personal mimeapps.list file, since there's a system wide file containing the default associations: it's either in /usr/share/applications/mimeapps.list or in /usr/share/applications/defaults.list (or both ).

The APT repository key of Oracle's OSS site has expired on 4th September (as probably many Debian/Ubuntu maintainers have found out by now). An apt-get update gave me the following error message:
The Oracle help page at Ubuntu's wiki contains the URL for the currently valid key.

I don't know of a simple APT command that could give the answer to the question of this post, thus I made a little awk script to filter the output of apt-cache policy to get what I want.

During upgrades between releases of a Debian (or Ubuntu) system you can end up with a lot of trash ... packages left over from earlier releases. Using the following command you can find packages that are not available from any of the APT repositories you've configured in /etc/apt/sources.list (or /etc/apt/sources.list.d/*):

These packages might have been manually installed or are remnants of a previous OS release. You should review the list and decide for yourself whether to keep them or purge them.

Note that the above command does not show packages for which the current version was manually installed from a DEB, but the package is available from a repository too.

For a more thorough list (packages for which the currently installed version is not from a repository ... including packages for which an update is available from the respective repository), try this:
(Don't forget to upgrade all packages to the current latest version or they'll be listed too.)

Mark Shuttleworth submitted the very first bug report on Launchpad back in 2004 ...

"Bug Description

Microsoft has a majority market share in the new desktop PC marketplace.
This is a bug, which Ubuntu is designed to fix.

Non-free software is holding back innovation in the IT industry, restricting access to IT to a small part of the world's population and limiting the ability of software developers to reach their full potential, globally. This bug is widely evident in the PC industry.

I've written a simple shell script to generate "signatures" of all the *.class files in two JAR files and compare these with diff. The output is pretty well usable to spot the (sometimes accidental) differences between two versions of the same library.

The easiest (and probably the most secure) way to do this is to install the tmpreaper package and change a few configuration lines in /etc/tmpreaper.conf.