dstat

This thread expands quite a bit more on the above topic: https://github.com/dstat-real/dstat/issues/156 For anyone who (like me) hadn’t come across this before, it might be interesting to read.

See also: https://github.com/dstat-real/dstat/issues/170

You are free to fork, but that doesn't make it right. Imagine a well-funded startup trying to make a name for themselves decided to fork the top 10 emerging open source projects, put their company name on them, and then spend millions in PR/marketing so that (A) it seems like they invented them, and (B) they fork the community. Are they free to? Is it right? What will it mean for the original authors and experts who created the software? I happened to be reading this yesterday: dstat is dead. Red Hat decided to rewrite it using pcp, so the original author has given up. https://github.com/dagwieers/dstat/issues/170 Is Red Hat free to? (probably). Is it right? Now that's where I'd want to see a strong reason.

If absolute share/ access were the problem, the line below wouldn’t hard-code it twice: https://github.com/dagwieers/dstat/pull/50/files The only bug in this PR that I can see is it might assume the system plugins are more important than the local overrides. Generally you’d put this sort of path in the least priority, to allow for /usr/local to override. That said, obviously hard-coding paths is worse than simply having a default, presumably relative to the current binary/file, and allowing end users and packagers to override/configure the defaults to suit their security preferences, with the default being that the entire package is unzipped with expected relative paths to files... or that’s how I would look at it. The only way to greater security would be to ship a Docker container, Snap package, or similar and mount your own filesystem

I submitted this PR long time ago: https://github.com/dagwieers/dstat/pull/50 that fixed an important installation issue, and it took the author 5 months to look at it and simply close it without providing any hints how to fix the problem in some other way. So I was discouraged to contribute further to the project.

Having read through this post and the previous comments[1] I have to say that RedHat did the right thing in the completely worst possible way. Stealing the project name was a mistake. The authors are right to be upset by the fact that people used to get their project when they did "yum install dstat" but now are getting a completely different (and not completely compatible) project. I think a lot of the friction could have gone away if they had just named it "pcp-dstat" or something similar, but instead they essentially took this person's namespace without discussion, and really for no good reason that I can tell. The other issue is that forking a project without even talking with the people running it is a very touchy subject. Ultimately it does look like the project was dead- even to the point where people were asking to contribute but

GitHub PRs being ignored seems totally true. https://github.com/dagwieers/dstat/pulls?q=is%3Apr+is%3Aclos...

pcp-dstat was implemented in 2018, FWIW. The blog post may have been written prior to the January 2019 dstat commits (before which the last commits were in 2016). More color: https://github.com/dagwieers/dstat/issues/156

From the git changelog, it doesn't appear to be completely unmaintained, but not very vital either: https://github.com/dagwieers/dstat/commits/master Red Hat's announcement (posted in February 2019), also cites lack of Python 3 support as another reason for replacing the original dstat, but Python 3 compatibility was added last January.

> I wish they had changed the name if they were forking or reimplementing without permission. Has the name not changed to "pcp", or am I missing something? "pcp dstat" appears to be a command, but that seems like a reasonable abbreviation for "hey pcp, please give me a dstat-like interface". [Edit] Correction. https://github.com/dagwieers/dstat/issues/156 says the following, so there is a compatibility symlink using the name "dstat". However the project name appears to be "pcp-dstat" or "pcp dstat". "Since there had been no meaningful work on the old dstat code in years, github PRs were being ignored, community developers requesting access to help were being ignored, and we have customers using it ... we were asked to make this as seamless a transition as possible, provide that compatibility symlink for /usr/bin/dstat to pcp-dstat, and re

The issue below has more details, it does look more complex than this post suggests? https://github.com/dagwieers/dstat/issues/156