There must be some kind of conspiracy behind all of the not-really-hot Hot Salsas I see at grocery stores. The end-goal must be to make people feel better about themselves because hey, they're handling the hot stuff.

Except that it's not hot at all, so I frequently feel cheated when I open up a jar of salsa I've never had before.

Hmm, I wonder if the FTC knows about this....

Okay, so here's why the pam_limits module doesn't work. Or at least, why it doesn't always work, and why it can't.

Let's look at what pam_limits does first. It sets process limits for the calling application at the point where it is called. This seems harmless enough, but it leads you to scary places.

Anyway, one of the things the pam_limits module lets you do is increase the value of one of your limits, say, the maximum number of open files. This, of course, requires superuser (root) privileges.

One of the other things the module lets you do is set a maximum on the number of processes the invoking user can have. The conflict here stems from the kernel assuming that the limit which a calling process sets using the setrlimit() syscall is to be applied to the calling user. If that calling user is root (as above), then you don't get to fork a new process to start a user shell, which is kind of important if you're handling interactive logins.

Why does this break? Applications call pam_open_session(), and therefore pam_limits, exactly once. And you can't be root and not root at the same time. The result is large numbers of support calls. Let's hear it for cross-platform standards everybody!

I run Raw Hide, the Fedora Core development snapshot, on my notebook and main workstation at work. And at some point, when attempts to upgrade Eclipse were stymied by a hard-coded package dependency on a package which went away, I started wondering why aren't we tracking Java dependencies automatically?

At this point I turn to Google to try to find out what kind of information is contained in all of those .class and .jar files which are littering my hard drive, and whaddaya know, there's all kinds of stuff in there, including the name of the class which the .class file defines, its superclass (the class from which it's derived), and the names, types, and types of parameters for every method. Sweet!

Several hours of scripting later, I discover that while you can massage the output of jcf-dump into pretty text, the fact that a dependency on foo.coolbar.method() recorded in one .class file can be satisfied by foo.bar.method() if foo.coolbar is derived from foo.bar kind of breaks you because RPM doesn't have any concept of inheritance for dependencies.

Suck.

At least we can track these things at the level of classes, which is better than what we had before. So you start tracking those, and then you realize that yes, there are packages in Raw Hide which include the entirety of other packages. Ouch, man, very ouch.