Hacker News Reader

Comment by detaro | Hacker News Reader

redhat announcing their "new dstat": https://www.redhat.com/en/blog/implementing-dstat-performanc...

The claim is that the original is no longer being maintained. Is that true? It changes a lot about what I would think of this move.

The git repo linked here has 6 commits on Jan 16, 2019. And Nov 23, 2016 the last new commits before then.

To contrast, Redhat's pcp dstat looks like it was mostly developed during 2018 (a period during which dstat had been totally inactive for 2-3 years):

https://github.com/performancecopilot/pcp/commits/master/src...

oh god. it's based on pcp o.O

Why is this significant enough to call it out without explaining why you did so?

18 months

Even if it isn't being maintained, I wish they had changed the name if they were forking or reimplementing without permission. There's a reason trademark law exists and doesn't require registration if you can prove the situation.

But yeah, it's a lot harder to fight Red Hat (soon IBM!) over that if the project is inactively maintained and there's no registration.

Still, whether legal or not, the name squat is not a good look for Red Hat.

> 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 remove the old package from RHEL and Fedora."

> community developers requesting access to help were being ignored

This is not true, I have not been contacted. I learned from Fedora's decision to replace Dstat with PCP months after it was already decided.

So it's not like I have had a choice. The choices I have today are:

1. Continue with a project, while Fedora/RHEL is shipping a tool by the same name (with 90% of my code)

2. Rename the original Dstat project, which would be silly

3. Discontinue the project

Option 3 is the path of least resistance. Option 1 and 2 would not bring any joy. At least someone will be paid for maintaining the tool.

GitHub PRs being ignored seems totally true.

https://github.com/dagwieers/dstat/pulls?q=is%3Apr+is%3Aclos...

Sure, and Red Hat being paid for RHEL shipping Dstat for a decade could have helped out. But instead they decided to replace it.

And as a result I don't see a point continuing a project with the same name.

>>>> community developers requesting access to help were being ignored

>>> This is not true

>> GitHub PRs being ignored seems totally true.

> Sure, and Red Hat being paid for RHEL shipping Dstat for a decade could have helped out. But instead they decided to replace it.

It's one thing to be upset due to a belief that Red Hat/others are at fault, but why lie to make your point?

Who lied about this ?

It's pretty clear we didn't accepted any PRs since December 2016 until Red Hat decided to replace our code, which started early June 2018. That's 18 months.

If I am upset about anything, it is this: https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7

> Who lied about this ?

> It's pretty clear we didn't accepted any PRs since December 2016 until Red Hat decided to replace our code, which started early June 2018. That's 18 months.

You are asking: "why didn't RH help out", you also didn't accept any pull requests. That surely would answer the question about why they didn't bother with pull request.

The question is then, how exactly do you think they have helped?

And where is the lie?

Maybe you should read the announcement and leave it at that.

Which PRs are you talking about? PRs I see there are either all from the last 4 hours or from 2016 and earlier that were merged.

4 hours ago was the last update to the PR, the pull requests are from years ago.

Oh wow, didn't realize. Yeah I see now. Thanks.

As part of archiving the project, I closed all open issues and PRs. That was what Github recommended me to do and I deemed best for everyone involved.

But isn't red hat calling their version 'pcp-dstat' and not simply 'dstat', so they aren't shipping with the exact same name.

They install a symlink from plain "dstat" to pcp-dstat. That's the exact same name part and plausibly objectionable.

That is done so that existing scripts keep working. Nobody complains about the LLVM linker installing itself as /usr/bin/ld, or systemd providing /sbin/init, do they?

I understand why they did it, but also why the author is complaining about it.

I am not really complaining, maybe unsatisfied of the direction it took and the consequences to other distributions without having a say.

But maybe people fancy the new PCP Dstat and accept their losses. In any case, money rules the world, Open Source ran by volunteers is dying and becomes less and less attractive.

Actually, yes they did. The use of /sbin/init was something that came up during the Debian Hoo-Hah. The conclusion was that it should be a symbolic link, and that there should be distinct packages providing that link and providing the real executable program image file that it points to.

* https://packages.debian.org/search?suite=jessie&searchon=con...

That's exactly what pcp-dstat does. /use/bin/dstat is a symbolic link.

The entire principle of a GNU based system is that everything is a reimplementation of original Unix tools with the same names but different provenances.

Like I said in a sibling comment, I understand why they did it, but also why the author is complaining about it. :-)

The issue below has more details, it does look more complex than this post suggests?

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.

The package was removed in Fedora 29, released October 2018.

Yes, and the plan to do this was conceived before June 2018.

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

Yeah, I added python 3 support after I learned that was the main reason for replacing it. It took me less than an hour to make it work on Python 3, including all (but 2) of the plugins.

And given that PCP is using most of the original code, they must have made the same changes to get Python 3 support.

maybe you shouldn't have waited until the absolute last minute to do this or it wouldn't have been replaced.

I am not sure what you are implying here. I have zero interest in maintaining the project. This was the last blow to a dying project.

The king is dead, long live the king.

No, the original was finished.

Feature complete, bug free software doesn’t need to have patches released every week. That is the ultimate goal of a small utility like this.

It’s a shame that so many developers mistake this state for “unmaintained”or “abandoned”.

The software isn't finished if the runtime it runs on has been EOL'd.

dstat, up until earlier this year (a couple weeks before that announcement), did not support Python 3 - and the author may have just merged RedHat's changes anyways. RedHat's "fork" supported Python3 for months at that point.

Yes, it was a useful tool, and what RedHat did was shitty but I can understand the motivation for not wanting to keep a Python2 install around just for one tool.

> I can understand the motivation for not wanting to keep a Python2 install around just for one tool.

I don't use a Red Hat distro but would this really only be one tool? On Arch I see the following packages depend on python2: mercurial [required], git [optional], texlive-core [optional], graphviz [optional], ...

Mercurial 5.0 is Python 3 compatible. The Python code in Git is Python 3 compatible. I don't know about TeXLive or Graphviz, though...

Confused, so why is Python 2 a requirement?

  Name            : mercurial
  Version         : 5.0-1
  Description     : A scalable distributed SCM tool
  Depends On      : python2
  Optional Deps   : tk: for the hgk GUI [installed]
  Required By     : None
  Optional For    : None
  Conflicts With  : None
  Replaces        : None
  Installed Size  : 25.95 MiB

Possible options:

1. Some of mercurial's bundled plugins are not Py3 compatible (I recall reading a discussion as an outsider a while back that some plugins are planned to be ported to Rust, not Python 3, but that may have changed) 2. Nobody involved in packaging it for Arch has had time to verify mercurial 5 on python 3.

So looking into this a bit more (and my edit window has expired), it's because the mercurial team themselves suggest not to package mercurial 5.0 for python 3 yet:

https://www.mercurial-scm.org/wiki/Release5.0

Weird that it says Windows is the issue but I'm seeing this on Linux.

RHEL8 doesn't include a Python 2 runtime that is supported for the whole life of the distro. There are a couple exceptions where Python 2 is used at build time, but that's it.

At the point when people started to work on pcp-dstat, it was clear that if you wanted X in the base distribution it had to be Python 3 compatible.

Arch doesn't promise support. Red Hat does. If software in Arch is unsupported in the near future but currently works, that's less of a problem than software in RHEL becoming definitely unsupported during the release lifetime.

Yes but that doesn't really answer my question. My question was if these programs use Python 3 then why would Arch -- which generally has the latest versions of programs unmodified -- have them depending on Python 2. You just explained why depending on Python 2 is not a problem... which is answering a different question.

Anything python2 is a problem, because Python 2 is officially end of life in January 2020. It is being dropped from all major linux distributions, along any software that depends on it.

RedHat 8 that just got released this month doesn't have it. Not sure when is the next release/update cycle for Arch, that will drop it. Keeping in mind that Arch probably doesn't care about doing things last minute or even after the due date.

Python 2 is EOL? Interesting. https://pythonclock.org/

I don't understand what you're trying to do with your comment. It might not be EOL quite yet, but 7 months into the future isn't very long.

Especially since RHEL 8 is gonna stick around for the next decade, it's a good idea to move as much stuff as possible to a newer platform that will continue to have security updates at least provided and written by the authors of the platform.

Reply on news.ycombinator.com