Add peers section to README

This commit is contained in:
Sean E. Russell 2020-06-03 08:34:31 -05:00
parent 5274d20897
commit dbaab87e71
3 changed files with 33 additions and 0 deletions

View File

@ -115,6 +115,31 @@ For more information on other topics, see:
**ca. 2020-01-25** The original author of gotop started a new tool in Rust, called [ytop](https://github.com/cjbassi/ytop), and deprecated his Go version. This repository is a fork of original gotop project with a new maintainer to keep the project alive and growing. An objective of the fork is to maintain a small, focused core while providing a path to extend functionality for less universal use cases; examples of this is sensor support for NVidia graphics cards, and for aggregating data from remote gotop instances.
## Alternatives
I obviously think gotop is the Bee's Knees, but there are many alternatives. Many of these have been around for years. All of them are terminal-based tools.
- Grandpa [top](http://sourceforge.net/projects/unixtop/). Written 36 years ago, C, installed by default on almost every Unix decendant.
- [htop](https://hisham.hm/htop/). A prettier top. Similar functionality. 16 years old!
- [atop](https://www.atoptool.nl/). Detailed process-focused inspection with a table-like view. Been around for 9 long years.
- [iftop](http://www.ex-parrot.com/~pdw/iftop/), a top for network connections. More than just data transfer, iftop will show what interfaces are connecting to what IP addresses. Requires root access to run.
- [iotop](http://guichaz.free.fr/iotop/), top for disk access. Tells you *which* processes are writing to and from disk space, and how much. Also requires root access to run.
- [nmon](http://nmon.sourceforge.net) a dashboard style top; widgets can be dynamically enabled and disabled, pure ASCII rendering, so it doesn't rely on fancy character sets to draw bars.
- [bashtop](https://github.com/aristocratos/bashtop), in pure bash! Beautiful and space efficient, and [deserves special comment](docs/bashtop.md). If you use anything other than gotop, I'd recommend bashtop.
- [ytop](https://github.com/cjbassi/ytop), a rewrite of gotop (ca. 3.0) in Rust. Same great UI, different programming language.
- [slabtop](https://gitlab.com/procps-ng/procps), part of procps-ng, looks like top but provides kernel slab cache information! Requires root.
- [systemd-cgtop](https://www.github.com/systemd/systemd), comes with systemd (odds are your system uses systemd, so this is already installed), provides a resource use view of control groups -- basically, which services are using what resources. Does *not* require root to run.
- [virt-top](https://libvirt.org/) top for virtualized containers (VMs, like QEMU).
- [ctop](https://bcicen.github.io/ctop/) top for containers (LXC, like docker)
### A comment on clones
In a chat room I heard someone refer to gotop as "another one of those fancy language rewrites people do." I'm not the original author of gotop, so it's easy to not take offense, but I'm going on record as saying that I think these are valuable and useful. They increase software diversity at very little cost, and are a sort of evolutionary mechanism: as people do rewrites, some are worse, but some are better, and users benefit. As importantly, most developers are really only fluent in a couple of programming languages. We all have *familiarity* with a dozen, and may even have extensive experience with a half-dozen, but if you don't constantly use a language, you start to forget the extended library APIs, your development environment isn't tuned, you're rusty with using the tool sets, and you may have forgotten a lot of the language peculiarities and gotchas. The barrier to entry for contributing to a software project -- to just finding and fixing a bug -- in a language you're not intimate with can be very high. It gets much worse if the project owner is a stickler for quality and style. So the original gotop author's decision to rewrite his project in Rust is a great thing. He probably made fewer design mistakes in ytop (we always do, on the second rewrite), and Rust developers -- who may have hesitated learning or brushing up on Go to submit an improvement -- have another project to which they can contribute.
Diversity is good. Don't knock free stuff.
## Stargazers over time
[![Stargazers over time](https://starcharts.herokuapp.com/xxxserxxx/gotop.svg)](https://starcharts.herokuapp.com/xxxserxxx/gotop)

View File

@ -433,6 +433,7 @@ func run() int {
ui.Render(bar)
}
// TODO https://godoc.org/github.com/VictoriaMetrics/metrics#Set
if conf.ExportPort != "" {
go func() {
http.HandleFunc("/metrics", func(w http.ResponseWriter, req *http.Request) {

7
docs/bashtop.md Normal file
View File

@ -0,0 +1,7 @@
# A comment about bashtop
Among tops, bashtop deserves extra recognition. It's one of the most impressive pieces of work I've encountered, on a couple of levels. For one, it is full of interesting, uncommon, and *useful* features. For another, it was accomplished with pure bash. In other words, it does far more with a far less sophisticated tool than it's peers. bashtop has a thoughtful and intelligent design of how information is presented. It has an attractive interface, with features like greyscale coloring in the process list that draw your eye to the heaviest processes. It's a beautiful, pleasant terminal UI, and I haven't yet seen anything as good, even among GUIs with all of the tools at their disposal.
bashtop is also utterly insane. It is a single, 140KB, 3,508-line bash script. The author claims to be doing a rewrite in Python, but that will never undo the admiration I have for what he accomplished with bash. Respect, Aristocratos.
If bashtop is so great, then why am I maintaining gotop? Two reasons. First, because I can't contribute to bashtop. I'm not that good with bash - not at the astronomic level Aristocratos is working at -) and I really don't *want* to be that good. I've been there, and bash -- while universal, very useful, and probably my go-to scripting tool -- is hell to maintain at any scale. 3,500 lines of bash is a headache, no matter how you slice it. And second, because it's relatively heavy on the CPU for a tool that's supposed to sit off to the side and be glanced at occasionally. But it is an inspiration, and I sincerely believe we all -- all of us developers -- can learn something about good UI design from bashtop.