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 could have gone away if they had just named it "pcp-dstat" or something similar, but instead they essentially took this person's namespace without discussion, and really for no good reason that I can tell.
The other issue is that forking a project without even talking with the people running it is a very touchy subject. Ultimately it does look like the project was dead- even to the point where people were asking to contribute but not getting responded to, and the fact that python2 is EOL and python3 support wasn't added until after this drama started shows that the project wasn't really "active". So while I do think they should have reached out, I totally understand why that slipped their mind.
So at this point I think RedHat should apologize and fix the package name.
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 activity" was the right excuse to make their action seem legitimate. Attempting to contact the project could have jeopardized that plan.
They could have just removed "dstat" from the distribution, and added a note that users can now use pcp-dstat. But now they made it impossible for users to add the original dstat. Let alone the support nightmare of having a different tool with the same name. There's no winning this one.
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.
You've misunderstood. The "dstat" package was removed from Fedora, rather than have its contents replaced. The package containing the new program is called "pcp-dstat", so they already did everything you think they should have done.
I submitted this PR long time ago: https://github.com/dagwieers/dstat/pull/50 that fixed an important installation issue, and it took the author 5 months to look at it and simply close it without providing any hints how to fix the problem in some other way. So I was discouraged to contribute further to the 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 moment I came across this thread that we're so up-in-arms about this when we're all happily using utilities that were produced by the very same process every day.
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".
this 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."
The change page says "The original dstat utility has reached end of life - it does not support python3 and there are no plans to update it." This may not have been right after all, but I don't think it's in bad faith. Perhaps FESCo should have dug a little deeper, but there aren't really any particular red flags indicating that that's warranted.
I'm open to suggestions, though -- we do want to continually improve our processes, and we do want to work well with upstreams. And, y'know, be better to long-time Fedora ecosystem friends.
Well, I had to find out this was planned and acted on after the decision was made and the alternative was written without any regards of the original project.
And that is fine if it would stay pcp-dstat as-is.
The most upsetting to me is that Dstat is no longer a python tool you can drop on a JeOS, Synology NAS or a WRT router to get it to work, you now have to install PCP and all its dependencies to make it work, which goes against the original design goals. (i.e. we used to support Python 1.5 for a long time to accommodate RHEL2.1 during its life-cycle)
Also, by taking the Dstat code, removing the plugin mechanism and replacing it with a PCP backend, writing a python plugin for Dstat is no longer possible. This is promoted as being a feature as "your plugin is now a config file" which is a bit disingenuous as you have to write a PCP backend which is a lot harder.
And it is not even a drop-in replacement, it only implements the built-in counters, not the full set of plugins (i.e. --top plugins are missing). So the argument that it needs to work as-is for existing customers does not hold true either.
By taking that name (with the Red Hat clout) there is no chance of anyone taking over maintenance without having to deal with 2 products using the same name, which I guess is forcing your wish on other distributions too.
Wrt. the change was properly announced. I bet the checklist was properly checked. Or to quote Douglas Adams:
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
I only know enough to get me in trouble, but pcp is a general "framework" for performance monitoring... they have pcp versions/rewrites of all types of traditional monitoring utilities like vmstat, iostat, top.
Note: they don't overwrite/replace those utilities on the command line. You can still use the traditional utilities same as it ever was. The pcp versions are called like so: "pcp dstat" or "pcp atopsar".
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?
Disclaimer, I work for Red Hat. That being said...
The big things for our customers isn't just support, it is stability. When you build your systems on RHEL 8 (just released), you will get 10+ years of support and patches for that system. Those changes are all guarenteed to be binary compatible, so the risk of patching ever impacting systems is low. If there is a critical security vulnerability (say Heartbleed in openssl), Red Hat will backport the fix to every supported version of RHEL. That means you get the security fix without (1) having to upgrade the entire openssl dependency and risk breaking something else and (2) without pulling in newer changes that might have their own vulnerabilities.
Going along with the stability, vendors can QA their products against RHEL as a known target.
Last reason for now, if you are in an industry with any kind of compliance requirements, like FIPS, Red Hat jumps through the hoops to get the certification. That makes RHEL the only option in many environments.
We had a vendor that we bought software from require, as part of the software requirements, both Red Hat and Oracle. This is not unique as many small specialized software shops do the same. I still have some government software that requires Windows 2008 and no other version is supported.
Extremely long life span (10 years), support if you want it, great community, great package manager, and in rhel 8 really great new features like appstream.
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 billion dollar company because it can and makes a mockery of not only open source colloboration culture but basic professional behavior. Has Redhat reached out to the author, made any requests, tried to work out some way forward, offered to pay for the brand name? Cmon this is simply indefensible.
>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 more than a year. And furthermore it was a Python 2 tool and the Python 2 EOL date is fast approaching.
I agree that the packagers should have at least left a note on GitHub (even if they thought it would go unread) - but clearly it was not a "maybe it's just mature and nothing needed to be changed" situation.
"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)
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
dagwieers, sorry this happened man that really fucking sucks. They should have done this differently and reached out to you for communication and stuff. Pretty disappointed with them for this. Hope you keep on and find other projects that excite you to work on.
It was already dead, so pragmatically there was nothing to do, this is just a swan dance on RH's bugzilla.
Yes, RH should and could have filed and issue saying that they started working on a fork/port-to-PCP, and they intend to provide the dstat executable. But usually at that point, the work is already started, and there's almost nothing to be done. How long RH should wait for that ticket? What if the maintainer says, wow, cool, I'll make a py3 version in 3 months. But RH needs it in 2? What if the maintainer disappears again?
Performance monitoring tools for enterprises can be very lucrative. Surely they’ll move to an “open core”, closed source commercial license for the useful bits, if they haven’t already.
[+] [-] tedivm|6 years ago|reply
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 could have gone away if they had just named it "pcp-dstat" or something similar, but instead they essentially took this person's namespace without discussion, and really for no good reason that I can tell.
The other issue is that forking a project without even talking with the people running it is a very touchy subject. Ultimately it does look like the project was dead- even to the point where people were asking to contribute but not getting responded to, and the fact that python2 is EOL and python3 support wasn't added until after this drama started shows that the project wasn't really "active". So while I do think they should have reached out, I totally understand why that slipped their mind.
So at this point I think RedHat should apologize and fix the package name.
[1] https://github.com/dagwieers/dstat/issues/156
[+] [-] dagwieers|6 years ago|reply
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 activity" was the right excuse to make their action seem legitimate. Attempting to contact the project could have jeopardized that plan.
They could have just removed "dstat" from the distribution, and added a note that users can now use pcp-dstat. But now they made it impossible for users to add the original dstat. Let alone the support nightmare of having a different tool with the same name. There's no winning this one.
[+] [-] devnullbyte|6 years ago|reply
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.
[+] [-] jsnell|6 years ago|reply
[+] [-] tedivm|6 years ago|reply
https://bugzilla.redhat.com/show_bug.cgi?id=1614277#c7
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] certik|6 years ago|reply
[+] [-] rurban|6 years ago|reply
[+] [-] clhodapp|6 years ago|reply
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 moment I came across this thread that we're so up-in-arms about this when we're all happily using utilities that were produced by the very same process every day.
[+] [-] zonidjan|6 years ago|reply
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".
[+] [-] proctor|6 years ago|reply
> "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
[+] [-] chubot|6 years ago|reply
Maybe Debian is more respectful since it's open source not backed by a company with enterprise customers?
[+] [-] mattdm|6 years ago|reply
The change page says "The original dstat utility has reached end of life - it does not support python3 and there are no plans to update it." This may not have been right after all, but I don't think it's in bad faith. Perhaps FESCo should have dug a little deeper, but there aren't really any particular red flags indicating that that's warranted.
I'm open to suggestions, though -- we do want to continually improve our processes, and we do want to work well with upstreams. And, y'know, be better to long-time Fedora ecosystem friends.
[+] [-] dagwieers|6 years ago|reply
And that is fine if it would stay pcp-dstat as-is.
The most upsetting to me is that Dstat is no longer a python tool you can drop on a JeOS, Synology NAS or a WRT router to get it to work, you now have to install PCP and all its dependencies to make it work, which goes against the original design goals. (i.e. we used to support Python 1.5 for a long time to accommodate RHEL2.1 during its life-cycle)
Also, by taking the Dstat code, removing the plugin mechanism and replacing it with a PCP backend, writing a python plugin for Dstat is no longer possible. This is promoted as being a feature as "your plugin is now a config file" which is a bit disingenuous as you have to write a PCP backend which is a lot harder.
And it is not even a drop-in replacement, it only implements the built-in counters, not the full set of plugins (i.e. --top plugins are missing). So the argument that it needs to work as-is for existing customers does not hold true either.
By taking that name (with the Red Hat clout) there is no chance of anyone taking over maintenance without having to deal with 2 products using the same name, which I guess is forcing your wish on other distributions too.
Wrt. the change was properly announced. I bet the checklist was properly checked. Or to quote Douglas Adams:
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
[+] [-] detaro|6 years ago|reply
[+] [-] astine|6 years ago|reply
[+] [-] throw7|6 years ago|reply
Note: they don't overwrite/replace those utilities on the command line. You can still use the traditional utilities same as it ever was. The pcp versions are called like so: "pcp dstat" or "pcp atopsar".
[+] [-] rurban|6 years ago|reply
[+] [-] JdeBP|6 years ago|reply
* https://unix.stackexchange.com/q/469780/5132
* https://unix.stackexchange.com/q/489477/5132
[+] [-] peterwwillis|6 years ago|reply
[+] [-] cpitman|6 years ago|reply
The big things for our customers isn't just support, it is stability. When you build your systems on RHEL 8 (just released), you will get 10+ years of support and patches for that system. Those changes are all guarenteed to be binary compatible, so the risk of patching ever impacting systems is low. If there is a critical security vulnerability (say Heartbleed in openssl), Red Hat will backport the fix to every supported version of RHEL. That means you get the security fix without (1) having to upgrade the entire openssl dependency and risk breaking something else and (2) without pulling in newer changes that might have their own vulnerabilities.
Going along with the stability, vendors can QA their products against RHEL as a known target.
Last reason for now, if you are in an industry with any kind of compliance requirements, like FIPS, Red Hat jumps through the hoops to get the certification. That makes RHEL the only option in many environments.
[+] [-] jteppinette|6 years ago|reply
I have exclusively used the Fedora line in enterprise environments (CentOS, OEL, RHEL).
The point about long term support is definitely #1.
[+] [-] protomyth|6 years ago|reply
[+] [-] lunchables|6 years ago|reply
[+] [-] snorrah|6 years ago|reply
[+] [-] icedchai|6 years ago|reply
[+] [-] throw2016|6 years ago|reply
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 billion dollar company because it can and makes a mockery of not only open source colloboration culture but basic professional behavior. Has Redhat reached out to the author, made any requests, tried to work out some way forward, offered to pay for the brand name? Cmon this is simply indefensible.
[+] [-] dralley|6 years ago|reply
>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 more than a year. And furthermore it was a Python 2 tool and the Python 2 EOL date is fast approaching.
I agree that the packagers should have at least left a note on GitHub (even if they thought it would go unread) - but clearly it was not a "maybe it's just mature and nothing needed to be changed" situation.
[+] [-] devnullbyte|6 years ago|reply
Its based on a entire language which is about to go EOL (Python 2)
[+] [-] thisgoodlife|6 years ago|reply
[+] [-] rain1|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] emily2749|6 years ago|reply
[deleted]
[+] [-] gigatexal|6 years ago|reply
[+] [-] anthony_doan|6 years ago|reply
Why should he change the project name when he originally have it first?
Also why did you have to frame it as rage quitting?
[+] [-] pas|6 years ago|reply
Yes, RH should and could have filed and issue saying that they started working on a fork/port-to-PCP, and they intend to provide the dstat executable. But usually at that point, the work is already started, and there's almost nothing to be done. How long RH should wait for that ticket? What if the maintainer says, wow, cool, I'll make a py3 version in 3 months. But RH needs it in 2? What if the maintainer disappears again?
It's not great, but it was abandoned. :(
[+] [-] marktangotango|6 years ago|reply