|
|
Subscribe / Log in / New account

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

January 6, 2009

This article was contributed by Bruce Byfield

On Windows, configuration options are stored in the registry, and are arcane enough that most people use a specialized editor, or cleaner, to remove unnecessary information. Recently, in a blog entry, Andrew Ziem argues that GNU/Linux needs the equivalent of a registry cleaner on Windows. He does so by pointing out examples of files and directories that remain in your home directory even after a package is deleted, and offers his new program BleachBit as a solution. However, while BleachBit -- currently at version 0.2.1 -- is easy enough to use, you have to wonder whether the minimal disk spaced saved or the privacy gained by running it is worth the effort -- especially when such advantages come with the risk of accidentally deleting information.

BleachBit is available as source code, or as packages for various recent versions of CentOS, Debian, Fedora, Mandriva, openSUSE, and Ubuntu, as well as SUSE Linux Enterprise and Red Hat Enterprise Linux. At 16 kilobytes, it downloads almost instantly. It is enough of a standalone program that, if necessary, you can install the different .DEB and .RPM packages on a wide variety of other distributions.

As an application, BleachBit is largely self-explanatory. You select an operation from the left hand pane, reading a brief description of it in the right hand pane if necessary, and click the Preview button to see what will be deleted, then the Delete button to actually remove files and directories. Operations complete in well under 20 seconds, even if you choose all of them.

The list of applications that BleachBit cleans is a long one, and grows with each release. In the current version, the supported applications include Bash, Beagle, Epiphany, Firefox, KDE and OpenOffice.org. BleachBit also supports proprietary applications, such as Flash and Opera, as well as desktop caches and recent document lists. Among those not supported are GNOME and Mozilla Thunderbird -- although, to be fair, BleachBit is in rapid development, and is only likely to increase its support in later releases.

[BleachBit]

The BleachBit interface is also in development. The descriptions of operations would be more visible with word wrapping, and, although a generic warning that deleted files cannot be recovered appears before anything is deleted, a confirmation specific to your choices -- and, perhaps, suggesting that you preview first -- might also be order.

Even more importantly, you should be aware that BleachBit does not clear your choice of operations after they are complete, even when you close and restart the application. That means that, unless you check carefully, you could easily find yourself performing an unintended operation, all the more so because the list of operations requires scrolling to see every item, even when the BleachBit window is maximized. Similarly, you need to remember that selecting a top-level operation, such as Firefox, selects a number of other operations, not all of which you necessarily want.

Useful, redundant, or dangerous?

The real question about BleachBit is not so much how to use it, but whether it is needed or even advisable to use. Ziem himself admits in his blog entry that "there is no promise your system will run much faster" if you use BleachBit -- and that "much" seems a euphemism for "any," if the results on my test systems are any indication. After all, unlike an unneeded entry in the Windows registry, most unused configuration files on GNU/Linux are simply not accessed, and therefore have no effect on system performance.

True, running BleachBit can free up hard drive space. However, because many configuration files are plain text, in many cases the space freed is measurable in kilobytes. The largest savings is likely to be in browser caches, but the total freed space is unlikely to be more than a gigabyte or two, an amount barely noticeable on recent computers. So, unless you are temporarily in need of more storage space until you can get out and buy an external drive, are on a network where your available space is limited, or take an anal-retentive pleasure in cleaning your system, you may find the saving of hard drive space a less than compelling argument for BleachBit. If you don't miss the space occupied by unnecessary files, then you won't see much need to reclaim it.

Probably the best argument in favor of BleachBit is the ease with which it protects your privacy. Many programs, such as Firefox, have their own controls for clearing associated files, and, if nothing else, you can set a file manager to view hidden files, and cherrypick the ones you want to delete manually. Yet, whether you wish to hide your viewing habits or simply believe in privacy, the convenience and efficiency of cleaning everything in your home directory from a single window is undeniable. By using the Preview, you can even learn from BleachBit the location and name of configuration files, which is more than you can say for many desktop administration utilities.

However, as with any desktop utility, the danger of BleachBit lies in putting power in the hands of users who may not be fully aware of what they are doing. Fortunately, unlike cleaners of the Windows registry, BleachBit does not affect system configuration, so it is not going to leave you with an unusable system if you accidentally delete the wrong file. Still, a mistake made when running BleachBit could mean the loss of valuable information stored in configuration files. After all, the whole point of having a BASH history is so that you don't need to recall or retype a command you have recently used. Similarly, if you miss that Sign ons under Firefox in the operation pane includes bookmarks and recently visited URLs, you could easily lose information that you were counting on being preserved.

Moreover, such mistakes are all the easier to make because of BleachBit's interface deficiencies (see above). Personally, I would be much more assured about BleachBit if these deficiencies were corrected, and actions within the application were hedged with more warnings and reviews of what you are about to do. Some users might complain about such additions, but making an application idiot-proof is a basic requirement if you are going to offer desktop users the power to make sweeping changes. After all, no matter what our experience, we can all be idiots sometimes, especially if tired or rushed.

Conclusion

None of these concerns are necessarily reasons to avoid BleachBit. Personally, I end with mixed feelings about the application. Possibly, BleachBit is an example of how following the Windows analogy too closely can lead to programs of minimal use. Alternatively, perhaps it empowers users to do what is otherwise more difficult and time-consuming, and allows them to protect their privacy without having to learn about their systems. Possibly, both could be true at the same time.

But, perhaps in the long run, the value of an application like BleachBit lies less in any improvements in performance or privacy that it offers than in the discussion of desktop and system design it provokes. Packages should be removing all traces of themselves when they are removed, but, as Ziem observes, many are not. Perhaps what is needed is not a tool like BleachBit, but stricter policies by distributions about the scripts that packages run before they are removed.


Index entries for this article
GuestArticlesByfield, Bruce


to post comments

Saving your $HOME space

Posted Jan 8, 2009 6:39 UTC (Thu) by eru (subscriber, #2753) [Link] (11 responses)

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.

Saving your $HOME space

Posted Jan 8, 2009 11:29 UTC (Thu) by rwmj (subscriber, #5474) [Link] (10 responses)

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.

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.

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.

Saving your $HOME space

Posted Jan 8, 2009 12:43 UTC (Thu) by eru (subscriber, #2753) [Link] (9 responses)

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

Posted Jan 9, 2009 4:30 UTC (Fri) by k8to (guest, #15413) [Link] (3 responses)

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.

Saving your $HOME space

Posted Jan 10, 2009 14:09 UTC (Sat) by epa (subscriber, #39769) [Link] (2 responses)

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.

Saving your $HOME space

Posted Jan 10, 2009 14:45 UTC (Sat) by nix (subscriber, #2304) [Link] (1 responses)

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

Saving your $HOME space

Posted Feb 16, 2009 22:06 UTC (Mon) by k8to (guest, #15413) [Link]

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.

Saving your $HOME space

Posted Jan 9, 2009 21:08 UTC (Fri) by felixrabe (guest, #50514) [Link] (1 responses)

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

Saving your $HOME space

Posted Jan 11, 2009 19:56 UTC (Sun) by eru (subscriber, #2753) [Link]

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.

Keep my data in my $HOME

Posted Jan 12, 2009 7:48 UTC (Mon) by rvfh (guest, #31018) [Link] (2 responses)

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!

Keep my data in my $HOME

Posted Jan 12, 2009 8:37 UTC (Mon) by nix (subscriber, #2304) [Link]

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

Posted Jan 14, 2009 15:25 UTC (Wed) by nlucas (guest, #33793) [Link]

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.

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

Posted Jan 8, 2009 6:45 UTC (Thu) by pascal.martin (guest, #2995) [Link] (2 responses)

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.

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

Posted Jan 8, 2009 6:58 UTC (Thu) by eru (subscriber, #2753) [Link] (1 responses)

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?

Posted Jan 10, 2009 14:40 UTC (Sat) by pascal.martin (guest, #2995) [Link]

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.

One other feature

Posted Jan 8, 2009 12:54 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link] (5 responses)

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.

One other feature

Posted Jan 8, 2009 22:54 UTC (Thu) by job (guest, #670) [Link] (4 responses)

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

Posted Jan 9, 2009 4:32 UTC (Fri) by k8to (guest, #15413) [Link] (3 responses)

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.

One other feature

Posted Jan 10, 2009 12:03 UTC (Sat) by mlankhorst (subscriber, #52260) [Link] (2 responses)

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

One other feature

Posted Jan 24, 2009 22:53 UTC (Sat) by muwlgr (guest, #35359) [Link] (1 responses)

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".

One other feature

Posted Jan 25, 2009 23:59 UTC (Sun) by dlang (guest, #313) [Link]

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


Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds