FSlint: annoyingly vague, but useful
Version 2.20 of FSlint is a program whose functionality is at odds with its design. On the one hand, a program for -- as the name suggests --- locating and removing unnecessary or useless material ("lint") from a filesystem is a handy one to install. On the other hand, a rough interface with cryptic buttons and options and a lack of anything except minimal help files makes accessing its options a bit of a challenge, especially at first.
If you choose, you can run FSlint using
/usr/share/fslint/fslint/fslint from the command line. This method returns a summary on all the items that FSlint searches for, which range from duplicate files, files with names incompatible with UTF-8, through installed packages to temporary files and empty directory. Alternatively, you can start FSlint with the command
fslint-gui. For once, the graphical version of the program seems to add all the functionality of the command line version, but you should probably run the command line version first, in order to understand some of the buttons in the GUI. Otherwise, you might not understand some of the abbreviations, since the help is otherwise confined to man and info files that tell you little of what to expect.
When you open the graphical version, at the top of the FSlint window is a pane for setting the search by path. By default, it shows the present working directory of the current user account, although perhaps the root directory would be a better choice. You can add additional paths through a file dialogue, or remove highlighted ones. The option for a recursive search path is enabled by default, which is a good thing, since otherwise you could easily miss the box labelled Recursive? on the far right of the pane, and waste your time in unproductive searches. On the Advanced search parameters tab, you can also list paths to exclude using the same controls; /dev and /lost+found are excluded by default, as well as extra parameters for the
When you have defined the search paths, you set the search item from a series of buttons in the bottom pane. Some of these search items have additional choices. For instance, you can search for temporary files of a minimum age, or for bad symbolic links of five different sorts.
Some of these choices are clear enough. For instance, anyone doing administration can be reasonably expected to know what absolute and symbolic links are; after all, FSlint is not a program for everyday users.
However, anyone can be excused for finding other choices obscure, at least at first glance. After a moment's hesitation, you should be able to figure out that the Dangling radio button for symbolic links probably refers to ones pointing to deleted files, but the distinction intended by the Suspect button is likely to be more elusive. Similarly, while the option under Bad Names to search for Invalid UTF8 mode presumably refers to compatibility with the encoding, what are the parameters for the sensitivity slider bar? What are you selecting when setting a search for temporary files to use the core file mode? Why do only name clashes and non-stripped binaries have an option for search $PATH? In such cases, any efforts at clarity seem to take second place to squeezing option names on to the GUI.
But, whatever the reason, in naming options, FSlint seems to desert users altogether. Users with intermediate proficiency in GNU/Linux administration can answer some of these questions, but the combination of obscure abbreviations and the lack of detailed helped files make what should be a relatively straightforward program needlessly harder to use. And this is not a program still in early advantages, but one that has gone through two major versions.
Once you decipher these options, your search begins with a click of the Find button at the bottom of the window. Depending on the search and the contents of your file system, FSlint's searches can take many minutes, so the program provides a stop button while a search is under weigh. However, if you persist, the results eventually appear in the bottom pane, from which you can save the results, or use the pane to delete selected results.
Incidentally, the Select button, if you right-click it, has a small menu of options for selecting results -- something you might never have guessed from the rest of the interface.
It is at this point that the usefulness of FSlint for cleaning your system finally becomes clear. You may want to be careful of false positives, or of hits in the results that you still need to keep on your system, but the program unquestionably provides a thorough set of results for anything that you search for. The first time you run it especially may surprise you with the amount of lint that it finds on your system.
Whether you decide to use FSlint will probably depend on your patience for its vagaries. However, if you put aside the interface problems, you may find FSlint a valuable maintenance tool. Whether you do, I suspect, depends on how long you have been using a computer (or, just possibly, on your early toilet training). If you started computing when a shortage of hard drive space wasn't a chronic problem, then FSlint is probably no more useful to you than a first-class file manager is in these days of search programs like Beagle.
However, if you developed your computing habits in the days when a 20 megabyte hard drive was an impressive storage solution -- or if you simply like knowing where everything is on your hard drive -- then FSlint is probably a program you'd like to add to your regular system maintenance. Have a little patience, and you'll find your restraint rewarded with useful information for cleaning your system.
Bruce Byfield is a computer journalist who writes regularly for the Linux.com and Linux Journal websites.
Bruce Byfield (nanday)
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- LiveCode Ltd.'s LiveCode
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide