# noscript noshow

If you're using the firefox extension "noscript", you're probably as annoyed by the forced redirection upon noscript updates as everybody else. Well, look for noscript.firstRunRedirection in about:config, and turn it to false.

Other than that, the noscript author is currently under heavy fire. Rightfully, I think.

# Size matters

Last week a friend asked me for help with a rather simple LaTeX problem (he wanted to include an image and rotate it, which you can achieve with the angle option of the \includegraphics command). Of course, you'd find this solution also in the manual of the graphicx package, and I thus recommended to install the texlive documentation. Rather thoughtless, as it turned out. He later informed me that he didn't intend to waste more than 10% of the limited storage capacity of his netbook just for 'fucking manuals'. Hey, I understand! I wouldn't do that myself. :/

However, what I regularly do is to check the size of the package I'm planning to install. All package managers I know offer this possibility. Try for yourself. ;)

Mandriva

urpmq -y <name>
urpmq -i <exact-name>


Debian

wajig search <name>
wajig detail <exact-name>


Arch

pacman -Ss <name>
pacman -Si <exact-name>


Suse

zypper search <name>
zypper info <exact-name>


Most likely, the texlive documentation will turn out to be by far the largest package avaliable for your distribution. On Mandriva, for example, it is 500 MB in size. No, you probably won't want to install this package on a netbook equipped with a 4 GB SSD...

# I can get no ... resolution

VirtualBox is getting increasingly popular, and with that, frustrated users of virtual machines having netbook-like screen resolution are getting more and more frequent. That's not really anybody's fault. From version 1.5, Xorg defaults to an automatic, zero-interaction configuration. It's attempting to guess the actual resolution of the connected display at boot time and does not rely on the trusted xorg.conf (which is generated, but contains just a few dummy entries). For a VirtualBox display, anything is possible in terms of resolution, and Xorg thus falls back to a conservative 1280x768.

This whole scenario is not even worth mentioning for experienced users of Linux, but for newcomers, who are not used to edit their xorg.conf, this current situation manifests an unsurmountable problem. Yet, it is really very easy to overcome. All you need to do is a little editing of your xorg.conf. ;)

Debian Squeeze, Gnome 2.22, Amaranth theme, 1400x1050. :)

All right, here you have the relevant subsection for copy and paste: :D

Subsection "Display"
Depth 24
Modes "1400x1050" "1280x960" "1024x600"
EndSubsection


# For experts only

In modern software design, the assumption that users are morons and shouldn't be allowed to do anything with their system tends to get more and more popular. This policy is certainly well-founded and complemented by plenty of experience, but in some cases, the results are at best humorous or just plain bizzare. The best-known example is the warning of firefox upon an about:config request:

I guess that's intended to be funny. Geek humour or something like that. Seen better, though. And most people find it simply annoying.

This example, however, is nothing compared to what Mandriva does to its users. Undoubtedly, the heart of any Linux distribution is its package management, and the sources (or repositories in Ubuntish) are its veins. In Mandriva, the GUI for configuring the software sources is drakrpm-edit-media:

See what I mean? The essential possibility to mark certain sources as "update" is greyed out. Even drakrpm-edit-media --help doesn't provide any helpful hints as to how to change this ... limitation *g*. That's because it's not a bug but a feature.

drakrpm-edit-media --expert


Now you are an expert.

# Search the package

Another short note in the series "useful package-manager commands" ;) .

Every serious user of Linux has experienced the problem of a missing shared library when compiling the sources of a third-party program. Now, you may know that you'd need lib64xyz.so.n for a successful compilation, but you may not know which (not installed!) package actually contains this particular library.

I know only two package managers which would deliver this information in a straightforward way:

Mandriva:

urpmf <exact_filename>


Debian:

wajig whichpkg <exact_filename>


(this one needs lynx and fping)

In Archlinux, pacman -Qo only searches local packages, as does OpenSuse's pin. :(

# Orphans

Modern package management systems do not only update and upgrade our system. They also clean it up. :)

urpmi:

urpme --auto-orphans


dpkg:

wajig autoremove


pacman:

| sort -nr | head -20