Tag Archives: information

since: Since you last checked

I promised I would get since onto these pages before the end comes, mostly because I don’t remember any other log viewer that has this behavior by default … and I want to be able to remember it in the future.


It’s hard for me to be sure though, after so many years and so many log utilities. :\

since seems different because, as you might have inferred from the screenshot, it only displays log data since the last time it checked. So you can see the last portions of pacman.log at the top of that image, then the repository update. The next invocation of since only shows the two lines that had been added.

I’m sure other tail-esque tools can do this, and possibly add a few nifty tricks in passing. It’s just a matter of finding the right flags and getting them in order.

For its own part, since keeps its state file in ~/.since, and you have the option to ignore it. You can also tell since to use a special state file, to run periodically, to ignore compressed logs, ignore missing logs, and a lot of other options.

I am not a real bloodhound when it comes to keeping an eye on logs, so at its best, since is useful … but only rarely. On my pseudo-desktop system, there’s almost no call for it.

On a more complex system or in a situation where log files are critical, it might save you some time trying to get the information you need. I’m willing to give it a thumbs-up. πŸ™‚

ncdt: An interesting evolution

Quick on the heels of tree and ddir, a loyal reader pointed out ncdt, which takes the tree model and adds a small feature or two.


As you can see, ncdt adds the size of files and directories as part of its default display. So in situations where it’s useful to see directory structure and size — such as labeling removable media, like CDs — it is probably more useful.

Unfortunately, I see no options to adjust what ncdt shows, so there are no “human-readable” (which I prefer) output flags or the like. What you see is what you get.

ncdt also promises to show “special” data for mp3 files, but the Debian version as well as the version I built on my Arch system from the Debian source package showed nothing. Even the sample screenshot in Debian doesn’t show anything “special” for mp3 files. Hmmm. 😦

It’s possible that there is an added dependency that I don’t have, or perhaps the mp3 files I tried post-date what ncdt is capable of analyzing. I checked the ReadMe and source files, but I got no hints. And the only home page I have for ncdt is the Debian package page above.

No matter. ncdt adds a little to the tree model and could probably, at one time in the past, show a little information about mp3 files. It’s an interesting evolution, even if it still needs some attention to reach fruition.

genstats: Quick statistical reports

I can see the usefulness of genstats almost immediately. Given a text file, you can pull out a frequency report with very little effort.


And since genstats handles its input and output in much the same way as cut, you should be able to get the information you want within just a few minutes of compiling it.

It may not be appealing to you to track word frequency in a flat text file, but consider what you could do with genstats and your average log file. That is the author’s suggestion, and the screenshot on the home page gives a good example of some advanced genstats usage.

My only complaint about genstats is so trivial that I’m embarrassed to mention it. In a file with 12 lines, and with four of the words in the second field being the same, the display should read “33%,” not “0.33%.” The latter is a third of a percent, while the former is a third of the whole. Or perhaps there is another calculation at work there, that I’m not sure about.

I get the picture though. And having said that, I suppose it’s worth mentioning that gentstats doesn’t give you a lot of control over the output. As best I can tell, that is the only style of report you’ll see from genstats.

genstats appears to be a free-roaming program; it’s not in Arch/AUR or Debian. So if you want something quick and easy to package, this might be one. πŸ˜‰

httping: Lots of flash and dash

When I first read the description for httping I took it to be a ping tool intended specifically for HTTP addresses. I couldn’t really see how that would be terribly different from plain old ping, since I’m in the habit of just feeding URLs to ping anyway.


Oh, but this is something even better than that. :mrgreen: httping has a lovely ncurses mode that shows all kinds of flashy, splashy, dashy color and metrics. And manages to cram it all into one small display.


I have a lot of the fancier effects turned on there; if you install the FFTW libraries from your distro (fftw in Arch; probably something from here in Debian) you can play with the phase meter and traffic history bars too.

Or turn all that off and get just the plain ncurses display. Or just feed it an address with no flags, and get something a lot like straight ping. But where’s the fun in that? πŸ˜‰

You could make the argument that pressing the phase display and the history graphs directly over the displayed text makes things hard to read, and I’d probably have to agree for the most part. However, I don’t remember too many other ping tools — or other network monitors, for that matter — that tried that, except perhaps for the venerable iftop, or its offshoot iftopcolor.

But personally, I like it. I think it works, and you have the option to remove it. httping is different, it’s colorful, it approaches a specific case and handles it completely but adroitly.

An easy decision: One gold star for httping: ⭐ Don’t spend it all in one place. πŸ˜‰

spew: For testing purposes

I’m suddenly inundated with testing a half-dozen new laptops here, so I don’t have a lot of time for writing up posts.

I did have a moment this morning to check out spew, which I believe is in the Debian repos, in Fedora and in their derivatives, but surprisingly not in Arch.


spew is a tool for testing I/O performance and generating workloads for those tests. What you see above is spew’s text-based interface, writing out a quick 128Mb file and checking the read-write stats.

By default spew works mostly in a CLI-fashion, as opposed to the whole-screen approach you see above. We haven’t seen too many I/O tools for the console — not counting iotop, which was the first one I could think of offhand — so it’s probably a good idea to keep this one around.

The next time I get an ancient laptop and a wicked-slow hard drive, I’m going to hunt down spew and see what it can tell me. Next time. πŸ˜‰