Just to pick up on your mentioning bug reports: (archived) Debian bug #664748 and Launchpad bug #555852 now seem to track this issue.

The kernel parameterizing of allow-discards could be an Archism: apparently in Arch, you notify GRUB of an encrypted root with (e.g.) ”cryptdevice=/dev/mapper/root:root:allow-discards”. This being picked up by Ubuntu users might be due to Arch’s wiki being referred to as ”Best reference” by Ubuntu wiki’s EncryptedFilesystems.

This answer is starting to look good. I also found allow_discards in dm-crypt’s current documentation; everything seems to imply it’s not a kernel parameter but an option for the dm-crypt device-mapper target. I’m still trying to find out if those can be passed on the linux command line. That would explain the instructions parroted all over, otherwise it is probably just misinformation.

As I said, net’s full of instructions without explanations. I’m after the explanations, not the procedure.

So, neither of the options is needed if the filesystem isn’t encypted? Why two options if all they do is enable one command to work?

A lot of SSD-related instructions online currently say you should add allow-discards and root_trim=yes to your GRUB_CMDLINE_LINUX. I have yet to find one that says why you should do that, i.e. what exactly (if anything!) do those parameters do. Where is the documentation on this and what does it say about those two parameters’ purpose?

According to Cryptsetup 1.4.0 Release Notes,

Since kernel 3.1, dm-crypt devices optionally (not by default) support block discards (TRIM) commands. If you want to enable this operation, you have to enable it manually on every activation using –allow-discards

cryptsetup luksOpen --allow-discards /dev/sdb test_disk 

but is it the same when passed to the kernel (via GRUB_CMDLINE_LINUX)?

Edit: Kernel.org’s list of kernel parameters doesn’t (currently, Jan 2013, at least) have either of these options.

From a similar question on ServerFault (and particularly one response there), one possible explanation for the disparity is that there are processes hanging on to files they’ve accessed on /tmp that have since been deleted.

# lsof | grep deleted 

will list such files along with the processes still attached to them.

>Lock version is not as clever as it sounds. It’s supposed to >do what it says on the tin, lock the version… But it only >locks it within Synaptic. Anything else that does package >upgrades (read: Update Manager, apt-get, aptitude, etc) >ignores this. (That’s supposed to be a blockquote, I but it doesn’t seem to work.)

RAM in common computers is addressed (i.e. referred to by programs) using sequences of bits that correspond to powers of two. When you’re using a 32-bit operating system, it means that programs have (at most) 32 bits available to them to describe each address. This 32-bit limit, fundamentally, lies in hardware: the x86 family of processors originally reserved just 32 bits for addresses.

The total number of different unique sequences you can organise 32 bits in is 4,294,967,296. For computers, this means you can only refer to that many different addresses in the memory. To point to more addresses (so that each address still remains unique) you must have more bits.

That large total number translates to 4 GB. As for why, in practice, it can actually be a quarter less than that, the 3 GB barrier Wikipedia article will explain.

Physical Address Extension or PAE, on hardware level, is an extension the 32-bit addressing in x86 processors: PAE processors have 36 bits for memory, thus extending the range of addresses available for the operating system (which then divides this memory among the programs). When you’re installing a PAE kernel, you’re in effect installing low-level operating system support for this extended x86 hardware.

When you have a 64-bit processor (as most modern processors are), you can run operating systems and applications that are built to address memory using those 64 bits. This gives them a total of ”18446744073709551616 different values, a number in excess of 18 quintillion”. In theory, at least, that means you won’t run out of addresses before you have more than 16,8 terabytes of RAM.

In Precise, window auto-maximize is disabled on monitors with a resolution above 1024 × 600 [1]. I have a bigger resolution, but I prefer maximized windows anyway. I want Update Manager to start maximized.

What I’ve tried so far:

1. In Compiz Config Settings Manager, I have Place Windows activated and ’Windows with fixed placement mode’ has windows matching the rule ”(name=gnome-terminal) | (name=update-manager)” set to ’Maximize’. With this, Gnome Terminal starts maximized, Update Manager does not.
2. In Compiz Config Settings Manager, I have set a Window Rules [2] rule to match ”name=update-manager”. Irregardless of any rules set or not, activating Window Rules results in not being able to bring out Unity Launcher anymore, Alt+Tab window switching becoming slow or nonfunctional entirely and the screen sporadically freezing completely. Not a viable option apparently.
3. I’ve installed Maximus [3] and started it. Update Manager ignores it (or vice versa).

I’ve not tried devilspie and would prefer not to. Having to configure something external for this would seem stupidly redundant with (the no-brainer) Maximus and all these Compiz options already available. I just can’t seem to make them work.

• [1] https://bugs.launchpad.net/ayatana-design/+bug/797808
• [2] http://askubuntu.com/a/53657/34756
• [3] How to configure my system so that all windows start maximized?