Hacker News Reader

Comment by jkaplowitz | Hacker News Reader

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.

View on HN

> 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. :-)

Reply on news.ycombinator.com