111–120 of 159 posts
Earlier quoted context omitted.
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.
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], ...
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?
* https://packages.debian.org/search?suite=jessie&searchon=con...
Earlier quoted context omitted.
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".
Then there is a lot of history that you do not know, starting with BSD and progressing through the late 1980s and early 1990s when there was a torrent of "clones" of things. The "Vixie cron" that you might even still be using is a "PD" clone of the Unix cron program, reimplemented from scratch with the same name. The van Smoorenburg "init" that you might have heard of was a clone of (an at the time sadly already out…
Earlier quoted context omitted.
>>>> 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
> 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?
Earlier quoted context omitted.
This isn't relative to the binary install, it's relative to argv[0]. It's the same security issue -- that argument is under user control. You can make a symlink to your target wherever you want and then argv[0] will be the symlink location. I don't think there is any secure way to get the current script path in Python.
so you install dstat in /usr/bin/dstat + /usr/share/dstat (because you are root), and an attacker creates /home/eve/bin/dstat with /home/eve/share/dstat/evil.py. why would you run /home/eve/bin/dstat? if eve can get you to run dstat from here ~/bin, why wouldn't she just have ~/bin/dstat with completely different contents? i'm still convinced this is cargocult security.
Earlier quoted context omitted.
I disagree, they were right to use the same namespace and its questionable how you conflate that to stealing. If something is abandoned, how can you steal it? The project was dead, PR's and issues were ignored and the lack of Python 3 support was a huge issue (which the developer pathetically tried to shut down discussion over by releasing a python 3 port just hours before closing the project). Changing the name spac…
Nobody stepped up to maintain the project, not even Red Hat. Some people have offered help, and I have send out a few GitHub invitations to people that offered, but no takers. I assume people offering to help only wanted to see their own contributions merged. I shouldn't be surprised people here take positions while not having been involved in the project or know the whole history. In my opinion, stopping the project…
Honest question: aside from "they provide Enterprise support", does anyone have a reason they would actually use redhat or centos for new servers? Why not use a Debian-derived one, which seems to both be more common, and have less constant creepy corporate influences?
I have been using dstat for years. It's a great tool. But why kill the project just because some company has a project with the same name? There is more than one distro, you know
Earlier quoted context omitted.
Then there is a lot of history that you do not know, starting with BSD and progressing through the late 1980s and early 1990s when there was a torrent of "clones" of things. The "Vixie cron" that you might even still be using is a "PD" clone of the Unix cron program, reimplemented from scratch with the same name. The van Smoorenburg "init" that you might have heard of was a clone of (an at the time sadly already out…
I'd like to add the common aliasing of vi->vim