LWN: Comments on "BleachBit: Does GNU/Linux need the equivalent of a Windows registry cleaner?"

Saving your $HOME space

k8to — Mon, 16 Feb 2009 22:06:36 +0000

For tradition, at least, /tmp should be global. I don't watnt to break any programs that rely on existing functionality. At least, that's how I'd do it on my systems.

One other feature

dlang — Sun, 25 Jan 2009 23:59:57 +0000

this sort of thing is very useful for many different programs nowdays. I ended up setting up a cron job to do a commit of 'interesting' files every min. it has saved me a few times when applications go haywaire (most commonly with firefox)

David Lang

One other feature

muwlgr — Sat, 24 Jan 2009 22:53:52 +0000

What is really needed, is probably sometihing like "KDE config keeper/explorer/reverter". To keep your configs in .git on each KDE startup. And let you see what so smart had KDE done with each config at what time. And of course return that into some previous state when everything looked and worked well. As KDE and its apps are prone to do some voluntary and overly-intellectual reconfigurations and fallbacks which the user only has to guess about how to revert or "fallforward".

Keep my data in my $HOME

nlucas — Wed, 14 Jan 2009 15:25:21 +0000

Note that "/tmp" and "/var/tmp" have different functions.

"/tmp" is for temporary files that can be completely cleaned up on system reboot (and many distros have init scripts that do exactly this).

"/var/tmp" is for temporary files that are to be preserved between reboots.

Google for FHS for more information.

Keep my data in my $HOME

nix — Mon, 12 Jan 2009 08:37:24 +0000

On my systems, /home is a) NFS-mounted, b) a RAID array, c) shared across
hosts. These are all undesirable things for /tmp, but desirable for home
directories.

/tmp should not be under /home.

Keep my data in my $HOME

rvfh — Mon, 12 Jan 2009 07:48:37 +0000

What's the big difference between using /var/.../%USER and /tmp or /var/tmp ?

I'd rather all user data were stored in their home, which may be encrypted rather than on some random part of the file system like /var/mail or /tmp...

I wish all files belonging to me (and therefore potentially personal and confidential) were in my $HOME where they belong.

So yes, $HOME/.tmp is a possibility , or just $HOME/.$appname/... back to square one.

At the end of the day, we have to rely on the app not making stupid use of our space, and can't do much about it appart from complaining and patching. It's Free Software after all!

Saving your $HOME space

eru — Sun, 11 Jan 2009 19:56:41 +0000

Omit the offending subdirectory during backup. Piece of cake with rsync

But not always with other backup methods. In fact, in a corporate environment you may not have any control over how the backup is made. And this still does not address the inherent inefficiency of using a network directory or USB stick for temporary storage. No, the cache directory really must be somewhere else than $HOME.

Saving your $HOME space

nix — Sat, 10 Jan 2009 14:45:08 +0000

You want pam_mount and a user-specific directory, really. You can still
*mount* it on /tmp...

BleachBit: Does GNU/Linux need the equivalent of a Windows registry cleaner?

pascal.martin — Sat, 10 Jan 2009 14:40:31 +0000

The problem I see is with the use of the word "clearly".

For example, some email readers organize the emails in a specific way (directory tree, database, etc...). You can argue that the format of the data being specific to the application, there is no point in keeping the files if the application is removed. On the other side, removing these files erases a long email history that could not be reconstructed.

Of course, configuration parameters specific to the application are good candidate for automatic removal. But these are usually small: not removing is no issue. If these are not small, then they do contain some valuable data. I would want a package removal process to fall on the safe side and not remove them.

Then there is the case of the nazi sysadmin (I met some) who decides that a specific application is useless crap and removes it; some users rebel and demand a reinstall. If that has never happened to you, you probably have never worked in a small high-tech company (in large corporations, to rebel is usually pointless). In other words, the user may not be aware the sysadmin decided to remove the package and might object to its removal.

At the end of the day, the only clear rule that works is: what is owned by the user is his and shall not be removed by third parties, no matter how well intentioned. A sysadmin who removes files owned by me is going to hear about it...

BTW, debian dpkg does not remove configuration files by default (it has an option for that) and that only covers system configuration, not users.

Saving your $HOME space

epa — Sat, 10 Jan 2009 14:09:03 +0000

Yes, given the ridiculous frequency of /tmp-race security holes, and the negligable performance difference for most apps, $HOME/tmp should be the default. It can be a symlink to /tmp/me for people who still insist on a separate /tmp partition for whatever reason.

One other feature

mlankhorst — Sat, 10 Jan 2009 12:03:24 +0000

It exists... gnome uses gconf, kde uses .kde/share/apps/appname ;)

Saving your $HOME space

felixrabe — Fri, 09 Jan 2009 21:08:44 +0000

Omit the offending subdirectory during backup. Piece of cake with rsync.

One other feature

k8to — Fri, 09 Jan 2009 04:32:21 +0000

No I agree with the grandparent.

We should have a single interface for accessing configuration data, and a single set of code for managing it. Fortunately this is already written, and it is called the filesystem.

Saving your $HOME space

k8to — Fri, 09 Jan 2009 04:30:49 +0000

There should be a per-user tmp, and the global tmp should be rarely, if ever, used.

I have no idea why we ever had a global tmp for most purposes. Laziness, I suppose.

One other feature

job — Thu, 08 Jan 2009 22:54:36 +0000

I disagree. That would add complexity and make it harder to use. A single _place_ however is a good idea, and that place is $HOME.

One other feature

smitty_one_each — Thu, 08 Jan 2009 12:54:19 +0000

It would be a Good Thing to have a single app that unifies the configuration details of various apps.
If it was possible to do it "right", and get substantial buy-in across the community.
Best wishes on that.

Saving your $HOME space

eru — Thu, 08 Jan 2009 12:43:16 +0000

What to do about it? I think you've identified a new class of storage: Per-user. Temporary in that it can be deleted at any time. But persistent in that the OS should keep it around as long as possible.

More precisely, can be deleted any time the user does not have a "session" on the machine. It would lead to bugs if applications would have to test if the data is still there while they are running.

With a new class of storage should come a new location. Something like $HOME/.tmp/, where applications can store this cached data, but if space is tight the OS may remove it (eg. at boot) without repercussions.

Not under $HOME, please. As I noted, it is often backed-up and/or non-local storage (in some cases even a USB stick), and should not be wasted for caching. A convention like /var/tmp/caches/$USER would be preferable. If the convention were commonly used, standard library functions could be added to make a sub-directory under this user cache in a secure way, making usage as easy for application writers as using the $HOME directory.

Saving your $HOME space

rwmj — Thu, 08 Jan 2009 11:29:27 +0000

Coming from an application developer's point of view, the reason is that it's very easy to stash stuff in the home directory. It's usually nothing more than getenv ("HOME") followed by creating a dot-file or subdirectory. You know the data will still be there next time the application is launched (even across reboots or long delays), and you know there won't be any security issues or conflicts as can arise when you use /var/tmp.

With a new class of storage should come a new location. Something like $HOME/.tmp/, where applications can store this cached data, but if space is tight the OS may remove it (eg. at boot) without repercussions.

Rich.

BleachBit: Does GNU/Linux need the equivalent of a Windows registry cleaner?

eru — Thu, 08 Jan 2009 06:58:02 +0000

Clearly, a deinstallation operation should never remove actual user-created documents or customizations, but it should remove temporary files and all cached data that can be automatically regenerated, if the user chooses to start using the program again.

BleachBit: Does GNU/Linux need the equivalent of a Windows registry cleaner?

pascal.martin — Thu, 08 Jan 2009 06:45:00 +0000

I may have a biased view above package removal, but I do not see why and how removing a package should remove user's data.

Why: user's data is user's personal property. As the "personal" indicates, it includes user's own data. What rights has the package manager to remove that data? This may happen while a user is logged on. How happy would you be to see files disappear suddenly under you?

How: a package is installed system-wide. A user data is per user. The package is removed by root, or one specific user if capabilities are used. What to do with other users data? Should the package manager start scanning all user's home directories and cleanup files under them? Is it wise to let the administrator or a simple user decide when it is appropriate to delete others users' files?

All considered, a cleaner application sounds not so bad. At least each user decides for himself if and when to delete things.

A note about the source of my bias: I have been hit a few times on Windows by applications, like drawing or document tools, that by default store the user's file into their own folder, something like c:\Program Files\XYZeditor\Documents. When you remove the software, the folder is gone, and so is your labor of love. Sad. Professionally, I work on train control systems that create historical records. We take _great_ pain of organizing our software so that we _do not_ remove any user data if our software is removed or upgraded. This data is important to the users, since it records their past operation events, which events have occurred (and these records may have legal significance) no matter if our software is removed or not.

Saving your $HOME space

eru — Thu, 08 Jan 2009 06:39:14 +0000

you have to wonder whether the minimal disk spaced saved or the privacy gained by running it is worth the effort

Unfortunately, several programs love to stash large amounts of cached data in their dot-directories under your home directory, so it is not always a minimal disk space we are talking about!

I have always found the use of $HOME for caching very annoying. It is wasting "prime real estate", because the home is usually backed-up (or at least more likely to be backed-up than other parts of the file system), and in many cases (especially in corporate environments) it is on a network file system (so using it for a browser cache just increases network traffic). Why cannot all apps use put their caches on /var/tmp or some such? Some already do.