Earlier quoted context omitted.
What language ? It is being quite factual really.
Time to go to Puppet Dag? :)
:D
Dstat project ended due to RedHat replacing it with its own dstat tool
91–100 of 159 posts
Re: Dstat project ended due to RedHat replacing it with its own dstat tool
#92Earlier quoted context omitted.
> 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 MiBRe: Dstat project ended due to RedHat replacing it with its own dstat tool
#93Devil'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".
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 of date) Unix init program. All of the stuff in GNU coreutils and other similar GNU toolsets was a deliberate reimplementation from scratch.
And then there are the Thompson, Mashey, Bourne, Almquist, Bourne Again, Korn, Z, and Watanabe shells. And BusyBox and ToyBox. And /usr/lib/sendmail . And the "mailx" utility. And "awk". And "vncviewer". And "getty". And so on.
* https://unix.stackexchange.com/a/508142/5132
* http://jdebp.uk./FGA/inittab-getty-is-history.html
* https://news.ycombinator.com/item?id=19988382
Re: Dstat project ended due to RedHat replacing it with its own dstat tool
#94Why not come up with a new name for the project instead of rage quitting?
> Why not come up with a new name for the project instead of rage quitting? Why should he change the project name when he originally have it first? Also why did you have to frame it as rage quitting?
It’s the way of the world that larger fish get to do as they please.
A simple name change and he can continue to do his work. It’s the idea of turning the other cheek. That or trademark the name I guess.
Re: Dstat project ended due to RedHat replacing it with its own dstat tool
#95Having 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…
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 space would have been problematic, as so many people use automation tools now to install package dependencies, rather than break their work because someone has zero intention of maintaining a project, they did the right thing and used the same namespace.
Had this been a case of RH disagreed with the developers direction or any factor around an active project, it would have been a shitty move, but considering the developer ignored any offers to help and let the project to fall into a stale un-maintained state, I don't see any grounds for him to throw his rattle out of the pram and blame RH here.
Re: Dstat project ended due to RedHat replacing it with its own dstat tool
#96This 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…
"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."
Its based on a entire language which is about to go EOL (Python 2)
Re: Dstat project ended due to RedHat replacing it with its own dstat tool
#97Devil'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".
almost every BSD tool is a rewrite of the original unix tools, and every GNU one is a separate rewrite too.
Re: Dstat project ended due to RedHat replacing it with its own dstat tool
#98this strongly reminds me of the hn post from five days back in which the main thread talked at some length about a very similar scenario > "He missed a big one: you have no way to stop Linux distributions from hacking up your software, and you'll suffer the consequences of whatever they do." https://news.ycombinator.com/item?id=19935648
Yeah I thought of the same comment. That is unfortunate. Maybe Debian is more respectful since it's open source not backed by a company with enterprise customers?
"respectful" as in let's wait years for a maintainer to come up with a solution and when we try to propose our own the maintainer trows a fit and turns it down?
Re: Dstat project ended due to RedHat replacing it with its own dstat tool
#99Having 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…
It didn't just slip their mind, they did not really care: https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7 The decision to do this was made before June 2018, 18 months after the last activity. One of the reasons cited was lack of activity, but that is no thanks to them, I guess. That is why I am convinced the goal was to replace it from the onset, there was no interest in helping out the project. In fact "no ac…
While Redhat did not handle this situation well you are also being very unfair to them. Why would they waste their time trying to contribute to a dead project? If I see that patches do not get merged and that bug reports go unanswered I will not bother doing anything because I know my time will be wasted, and I do not fault RedHat for doing the same.
What they should have done is tried to reach out to you before forking.
Re: Dstat project ended due to RedHat replacing it with its own dstat tool
#100Earlier quoted context omitted.
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
They didn't even try to contact the author?!
dstat was basically presumed dead due to lack of upstream activity. I recall the internal discussion was something like
A: "Whoa, there is no dstat in RHEL8? Customers are gonna complain."
B: "Yes, it's because it's Python 2 only and upstream is dead. Tell customers to use PCP"
A: "Srsly? Nobody thinks of the scripts? Besides, dstat output is so nice."
C: "Well, there is some toy example to print pcp data in dstat format."
A: "Do we really want to tell customers 'there is a toy example'?"
C: "Give me a day or two to pimp it up."
And then C got a bit carried away. :-)