81–90 of 159 posts
Earlier quoted context omitted.
Apparently reusing the name without talking to the author was a conscious decision on their behalf- https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7
meh. ultimately this is OSS. the maintainer was negligent. if you're not a good OSS maintainer, you don't deserve to maintain control. it's not reasonable to be indefinitely patient when the original author shows no initiative to maintain their project
Devil's advocate: Isn't this kind of behavior how we ended up with what became the POSIX command-line utilities? A bunch of people re-implementing and extending each other's stuff without changing the name? I know that the word has changed a bit since then and that it's a bit different to appropriate a soul-less corporation's command names vs an individual volunteer.. It just happened to strike me as odd at the momen…
I don't know that massively popular utilities were ever "reimplemented" with the same name. Ported, or forked, or extended, but not reimplemented. It's not clear to me if pcp-dstat is a fork or a total rewrite. Also, most of those utilities were named things which solely described what they did. It's a bit different to make a new "cut" vs a new "clhodapp".
Earlier quoted context omitted.
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?
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 coul…
Apparently reusing the name without talking to the author was a conscious decision on their behalf- https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7
Earlier quoted context omitted.
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?
Reminds me on moreutils parallel (C), hijacking GNU parallel (perl), and changing the command line options. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597050
Earlier quoted context omitted.
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 Pyth…
Python 2 is EOL? Interesting. https://pythonclock.org/
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.
This is undoubtedly shady behavior. dstat is a widely regarded and mature tool. Looking at its repo for 'activity' without context - maybe nothing needs to be changed and its working as designed - is completely disingenious. Why should repo activity without context be used as an indicator of anything in discussion instead of focusing on what Redhat has done? This is openly hijacking an open source project by a billio…
>Looking at its repo for 'activity' without context - maybe nothing needs to be changed and its working as designed - is completely disingenious. >Why should repo activity without context be used as an indicator of anything in discussion instead of focusing on what Redhat has done? "Activity" doesn't just refer to commit traffic. People were filing issues and making pull requests and not getting any responses for mor…
Are you saying anyone running a Python2 project can expect to have Redhat reimplement it in Python3 secretly and have people defend it on HN? This kind of behavior is simply indefensible.
It's obvious there is a culture clash of open source developers sponsored or working for corporates conflating heavy activity on Github that they are paid to perform as their day jobs as the only open source model. But open source was traditionally about people having other jobs and using their spare time to develop open source without profit motives because they believed in the movement. They certainly did not face corporates and paid developers analysing their frequency of contributions to dismiss their efforts and justify an unethical takeover.
Earlier quoted context omitted.
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 Pyth…
> 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], ...