Re: clearing out /tmp

[Jeff Licquia <jeff@licquia.org>]

For the record: As a Debian advocate, and more importantly as someone
whose livelihood partly depends on providing alternatives to RH, I don't
agree with this RH-paranoia meme floating around.  It's stupid and
distracting, and flies in the face of the facts - especially when RH is
compared to Microsoft.

Some of the things RH does are good, and some aren't.  Their hands are
tied by the GPL regarding Microsoft-style world domination.  The rest of
the stuff they do bad seems to me to be simply bad advice or other forms
of incompetence, not malice.  And, don't forget, they do a lot of good
for the community as well.

On Sun, 2003-04-13 at 13:59, mike808@users.sourceforge.net wrote:
> [Steve]
> > I just checked, and it definitely comes with both Mandrake and SuSE,
> > but not Debian.
> 
> Apparently you didn't check very well. It's not part of the 8.1 normal install.
> "comes with" WRT to SuSE is a bit misleading, as there is 7 CDs worth of
> "comes with" software. Not all of it is installed. The MDK, I can believe,
> since its roots are closer to RHs. And for many, if it's not in Debian, 
> it's not RealLinux(tm). It also means it's not in Debian-based distros like
> Connectiva, Xandros, Lindows, Lycoris, Libranet, and others.

The Debian-based speculation here is misleading (probably through
ignorance).  I can't comment on the other distros.

The tmpreaper package Conflicts and Replaces tmpwatch.  When installed,
the initial changelog items reference the package as "tmpwatch".  The
name change entry looks like this:

tmpreaper (1.4.1-1) unstable; urgency=low

  * Renaming from `tmpwatch' to `tmpreaper' to split away from RedHat, who
    released a `tmpwatch-1.4' that had zero of the patches I sent them.

 -- Karl M. Hegbloom <karlheg@inetarena.com>  Sun,  7 Dec 1997 13:42:03 -0800

This proves that tmpreaper is a fork of tmpwatch, and not an independent
effort.  So, tmpwatch should be considered "RealLinux" to those that
consider Debian the bulwark of freedom.

It's likely that Karl's patches were irrelevant to Red Hat, which would
make a fork entirely appropriate.

> > A quick Google search shows that Debian comes with a
> > similar (apparently enhanced) utility called tmpreaper.
> > 
> > So my point still stands.  This is a problem that the average Linux
> > user should not need to deal with under normal circumstances.
> 
> Just because some package is available for a distro does not mean it's
> part of the default install. His system has a very good chance of NOT having
> the item you point out that RH does by default.
> 
> And, a lookup up of the history of this "tmpwatch" package, it seems it is
> a Redhat-developed utility - by RH, for RH (by Erik Troan, and Preston Brown,
> both of RH). Just because RH "thunk it up" doesn't mean everyone else 
> "obviously" must blindly adopt stuff they put in their distro. Though some do,
> such as the former "LinuxOne" distro, which thankfully, is gone.
> http://www.linuxworld.com/linuxworld/lw-1999-11/lw-11-linuxone_p.html

No, but every distro should address the problem in some way, either with
programs like tmpwatch and tmpreaper, or with startup scripts.

It's kind of like logfile handling.  Everyone rotates logfiles and
deletes them.  Some, like Debian and RH, use logrotate.  Others may have
something else.  But no one can afford to ignore the problem.

And this was exactly Steve's point.  "This is what RH does; it's likely
that your distro does something similar if you don't run RH."  I see
nothing objectionable to that, nor do I see any implication that people
need to upgrade to RH to get that functionality.

> I don't doubt your sh^Hkill in RH. You should keep in mind that there are 
> plenty of other distributions that are not RH, and that there's a 
> reasonable chance that someone posting a question isn't running RH.

Similarly, you should keep in mind that people can comment on what they
wish.  If the user used RH, his question would be answered.  If not, he
would have had to wait for a non-RH question, or asked more
specifically.

> As you said, if the poster was running RH, they wouldn't have the issue.
> Since they did make the post and apparently does have the issue, it would 
> be reasonable to conclude they therefore *do not* run RH. Therefore, 
> RH-specific advice is pretty irrelevant, don't you think? Unless the 
> "solution" involved "upgrading" to RH in order to obtain this utility you 
> mention, the "rah-rah for RH" or "works for me" isn't overly helpful.

Or, possibly, the poster simply didn't know if it was handled or not. 
If /tmp is always clean, that could mean you have something cleaning it,
or it could mean that it's not being used.

> There also isn't a project page for it, so it's still very closely tied to RH.
> Either that, or there are several forks and projects calling themselves 
> "tmpwatch" for the other distros. Neither of which leads me to believe that
> tmpwatch is an equivalent Open Source package to something like e2fsprogs.
> 
> Just because something is GPL doesn't mean it's any good or useful to 
> anyone other than the author.

tmpwatch is free software.  If it's valuable, use it.  If it's mostly
valuable but not quite right, fork it, like Debian did.  If it's not
valuable, use something else that is.  In all cases, RH deserves credit
for providing something that could be at least partly useful.

And, more importantly, don't bash someone for providing part of an
answer.  Just fill in the blanks (if you can).
-- 
Jeff Licquia <jeff@licquia.org>

-
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.