11 ms·

Dstat project ended due to RedHat replacing it with its own dstat tool

168 points by tanelpoder 7y ago

throw7 7y ago
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".
emily2749 7y ago
See the video of most dangerous bird and how he killed owner https://howto105.blogspot.com/2019/04/most-dangerous-bird-killed-owner-in-usa.html https://howto105.blogspot.com/2019/04/most-dangerous-bird-ki... Funny dog driving own car See his video on link below http://bit.ly/2WdSKpA http://bit.ly/2WdSKpA Cute dog going for school like human baby see his cute video I am sure you can't stop laugh http://bit.ly/2Wq6Ynr http://bit.ly/2Wq6Ynr United nation recently showed the real face of india See what they said in report After knowing this I am sure you will hate them if you have soft heart https://youtu.be/oUskNtdWeIY https://youtu.be/oUskNtdWeIY Best way to get rid from face moles with the help of home remedies its easy and simple way You don't need to waste money for this https://zoomtips.blogspot.com/2019/05/easily-get-rid-from-face-moles-with.html https://zoomtips.blogspot.com/2019/05/easily-get-rid-from-fa...
icedchai 7y ago
I literally use dstat all the time! This is very sad.
- op00to 7y ago
  Why? What has changed? Do you use the plugin functionality of dstat, or do you just use the dstat command? If it's the latter, then you can do everything you could with dead-dstat and more with pcp-dstat.
  - icedchai 7y ago
    It saddens me when a useful, good open source project closes. I realize I can still use it, and I will... That's not the point.
detaro 7y ago
redhat announcing their "new dstat": https://www.redhat.com/en/blog/implementing-dstat-performance-co-pilot https://www.redhat.com/en/blog/implementing-dstat-performanc...
- astine 7y ago
  The claim is that the original is no longer being maintained. Is that true? It changes a lot about what I would think of this move.
  - codewiz 7y ago
    From the git changelog, it doesn't appear to be completely unmaintained, but not very vital either: https://github.com/dagwieers/dstat/commits/master https://github.com/dagwieers/dstat/commits/master Red Hat's announcement (posted in February 2019), also cites lack of Python 3 support as another reason for replacing the original dstat, but Python 3 compatibility was added last January.
    - loeg 7y ago
      pcp-dstat was implemented in 2018, FWIW. The blog post may have been written prior to the January 2019 dstat commits (before which the last commits were in 2016). More color: https://github.com/dagwieers/dstat/issues/156 https://github.com/dagwieers/dstat/issues/156
    - jsnell 7y ago
      The package was removed in Fedora 29, released October 2018.
      - dagwieers 7y ago
        Yes, and the plan to do this was conceived before June 2018.
    - dagwieers 7y ago
      Yeah, I added python 3 support after I learned that was the main reason for replacing it. It took me less than an hour to make it work on Python 3, including all (but 2) of the plugins. And given that PCP is using most of the original code, they must have made the same changes to get Python 3 support.
thisgoodlife 7y ago
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
- type0 7y ago
  It is the Big Gorilla, the silverback if you like. For other distros that would be even more confusing when some of their tools will be ported there.
- pas 7y ago
  The project was already dead. But now the maintainer[s] found time to complain about how evil RH simply opted to provide a py3 compatible replacement and provide it as dstat.
  - dagwieers 7y ago
    That's not exactly what happened, but great to see you are making improvements in your fiction-writing skills :-) Keep it up !
deleted 7y ago
[deleted]
marktangotango 7y ago
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.
- loeg 7y ago
  That isn't Redhat's model. They open the code (it's mostly 3rd party OSS anyway), including packages (hence, CentOS) and sell access to the updates system and support contracts.
  - lathiat 7y ago
    There's a couple of areas that's not actually true. For example their "insights" package which has rule based detection of problems to fix etc is open source but the actual ruleset is not.
  - mindcrime 7y ago
    That isn't Redhat's model. Well... it hasn't been so far. But this isn't the old Red Hat anymore. This is IBM Hat. And for all the talk about keeping Red Hat mostly independent or whatever, I think we all know that's bullshit. Acquiring companies always give that little dog and pony show, and it never holds up in the long-term. There's no way that IBM culture won't wind up infecting Red Hat. Now whether that's a good thing or a bad thing is a question I'll leave to the philosophers. But I'd be very leery of assuming anything regarding what RH will or won't do going forward.
    - klohto 7y ago
      Every single thread someone has to bring it up. The acquisition isn’t even closed yet and suddenly every decision done is mysteriously pushed by IBM. There is more than enough people who have their own minds. That is the RH culture, if this freedom is touched they will just quit. IBM won’t affect RH in any way, Jim is not an idiot because he knows this would destroy RH and IBM are also not idiots because it would destroy they purchase.
snorrah 7y ago
Curious, i know dagwieers from being involved in the Ansible project (RedHat owned). Seems friction is occurring, given the language in his post.
- dagwieers 7y ago
  What language ? It is being quite factual really.
  - sdiepend 7y ago
    Time to go to Puppet Dag? :)
    - fwdIT 7y ago
      :D
tedivm 7y ago
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. [1] https://github.com/dagwieers/dstat/issues/156 https://github.com/dagwieers/dstat/issues/156
- deleted 7y ago
  [deleted]
- jsnell 7y ago
  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.
  - tmyklebu 7y ago
    What makes you think he misunderstood? What happens on fc30 when you 'yum install dstat' as he suggested? This webpage listing the contents of the fc30 pcp-system-tools package: https://fedora.pkgs.org/30/fedora-updates-x86_64/pcp-system-tools-4.3.2-1.fc30.x86_64.rpm.html https://fedora.pkgs.org/30/fedora-updates-x86_64/pcp-system-... lists a file called '/usr/bin/dstat'. The pcp-system-tools package obsoletes a package called 'dstat'. If you go to https://pkgs.org/download/dstat https://pkgs.org/download/dstat, and look under "Fedora 30," you get pcp-system-tools. [Spoiler: 'yum install dstat' installs pcp-system-tools, which has a symlink /usr/bin/dstat -> /usr/libexec/pcp/bin/pcp-dstat.]
proctor 7y ago
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." https://news.ycombinator.com/item?id=19935648 https://news.ycombinator.com/item?id=19935648
- chubot 7y ago
  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?
  - bonzini 7y ago
    Not really, remember the ssh key fiasco which was also due to a Debian-only patch. (Disclaimer: I work for Red Hat)
  - raverbashing 7y ago
    "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?
    - dagwieers 7y ago
      Is that what happened? I remember it differently...
  - mattdm 7y ago
    Eh. Although we don't always do things perfectly, Fedora has a pretty strong policy of working with upstreams first. By contrast in my personal experience as a developer of something that got packaged in Debian, I discovered later that that package had a bunch of patches added, a man page written (!) and so on, none of which was bad, but also none of which was fed back to me at all. (In case not obvious: I work for Red Hat on Fedora.)
peterwwillis 7y ago
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?
- cpitman 7y ago
  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.
  - user5994461 7y ago
    I'd say both stability and update. Debian never upgrades anything (unless security issue). All packages are frozen at the time of the initial major release. Have fun using curl/htop/nginx/libreoffice from 5-10 years ago, plenty of obscure bugs and missing command line flags. RHEL actually maintain their system packages.
- jteppinette 7y ago
  > which seems to be more common I have exclusively used the Fedora line in enterprise environments (CentOS, OEL, RHEL). The point about long term support is definitely #1.
- protomyth 7y ago
  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.
throw2016 7y ago
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.
- dralley 7y ago
  >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.
  - throw2016 7y ago
    This is muddying the waters. Surely if you have gone through the trouble of looking at the repo and finding these pull requests you would also know the context and should then share it to give others here a context. Without that you are just here making 'vague' charges given dstat is a well known, highly regareded and mature tool. The Python3 port was already done by the author so the python2 eol seems a complete non sequitor. Again a rush to condemn without good reason. 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.
certik 7y ago
I submitted this PR long time ago: https://github.com/dagwieers/dstat/pull/50 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.
- rurban 7y ago
  You added a security problem. The fix is obvious for everybody working in security, but it's questionable if it should be discussed there.
  - lstamour 7y ago
    I can see how the original CVE patch removed using the current working directory for loading plugins, but it seems like less of a security issue to simply look up one directory relative to the current binary install, assuming the binary is stored in ./bin after being built and plugins would be stored in ./shared ... Now, it might be inconsiderate to look up a folder when one could be preconfigured based on a common root or home folder, but it doesn’t necessarily seem as bad to trust the parent folder of a binary as trusting the current working directory’s contents?
    - Kalium 7y ago
      How do you arrive at the conclusion that looking at `./plugins/` is bad, but `../shared/dstat` is more acceptable? At first blush, the attack vector would seem to be exactly the same. Adding the extra layer of indirection does not seem, to my eyes, to add any significant extra layers of security. Both seem essentially untrustable from the perspective of the binary. Can you help me understand what I've missed in your explanation? I can also see where someone might not want to endlessly re-debate an old security decision.
      - lstamour 7y ago
        Sure. The original security bug was lines 31-32, but the new patch referring to the parent directory is a variation of line 30, untouched here: https://bugs.gentoo.org/attachment.cgi?id=210509&action=diff https://bugs.gentoo.org/attachment.cgi?id=210509&action=diff CWD is far worse a risk, because it changes every time the command is run. By comparison it could be assumed that a secure install of the software is in a trusted location, and this just gets the parent root of that location. Of course, it’s better if it’s documented, but I see no difference between this and $JAVA_HOME’s approach of ./bin, ./share, etc. It could be argued this is better—no environment variables can override the default. If you install the app to /tmp/bin that’s your own fault...
rurban 7y ago
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 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597050
- JdeBP 7y ago
  This sort of thing happens regularly. For another example of many, witness the effects on users of the change of the "mailx" command in Debian. * https://unix.stackexchange.com/q/469780/5132 https://unix.stackexchange.com/q/469780/5132 * https://unix.stackexchange.com/q/489477/5132 https://unix.stackexchange.com/q/489477/5132
gigatexal 7y ago
Why not come up with a new name for the project instead of rage quitting?
- anthony_doan 7y ago
  > 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?
  - gigatexal 7y ago
    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.
    - ben0x539 7y ago
      Would redhat ship dstat under the new name?
      - gigatexal 7y ago
        They should have shipped the original devs version or forked it and worked with him to get it supported and submitted their RH changes upstream etc.
    - anthony_doan 7y ago
      > It’s the idea of turning the other cheek. I had to look this up. > refrain from retaliating when one has been attacked or insulted. I don't think he have retaliated in anyway, at least from the github commit message and the blog post. He just decided it wasn't worth his free time to deal with this problem. Maybe there is a disagreement with the definition of rage quitting but it was his open source project and his free time. I don't think it's rage quitting if he wants to quit and do something else with his free time. Rage quitting have a negative connotation such as flipping table or that scene from the movie Half baked where the dude cussed everybody out before quitting. He seems to have a career, whether you care or not, labeling at such may be detrimental to his career. Regardless of if you care or not, I hope other people refrain from speculating or do huge leaps of conclusion base on little or no facts that can damage other people's ability to make a living.
clhodapp 7y ago
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.
- zonidjan 7y ago
  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".
  - deleted 7y ago
    [deleted]
  - JdeBP 7y ago
    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 https://unix.stackexchange.com/a/508142/5132 * http://jdebp.uk./FGA/inittab-getty-is-history.html http://jdebp.uk./FGA/inittab-getty-is-history.html * https://news.ycombinator.com/item?id=19988382 https://news.ycombinator.com/item?id=19988382 * https://news.ycombinator.com/item?id=17005677 https://news.ycombinator.com/item?id=17005677 * https://unix.stackexchange.com/a/316279/5132 https://unix.stackexchange.com/a/316279/5132
mattdm 7y ago
So, from a Fedora Project point of view, I'm not really sure how we could have done this better. This change was properly announced and publicized as https://fedoraproject.org/wiki/Changes/MergeDstatAndPerformanceCoPilot https://fedoraproject.org/wiki/Changes/MergeDstatAndPerforma... and approved by FESCo (the Fedora Engineering Steering Committee) in August 2018 (https://pagure.io/fesco/issue/1956 https://pagure.io/fesco/issue/1956). 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 7y ago
  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.”
rain1 7y ago
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.

168 points by tanelpoder 7y ago

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".

emily2749 7y ago

See the video of most dangerous bird and how he killed owner https://howto105.blogspot.com/2019/04/most-dangerous-bird-killed-owner-in-usa.html https://howto105.blogspot.com/2019/04/most-dangerous-bird-ki... Funny dog driving own car See his video on link below http://bit.ly/2WdSKpA http://bit.ly/2WdSKpA Cute dog going for school like human baby see his cute video I am sure you can't stop laugh http://bit.ly/2Wq6Ynr http://bit.ly/2Wq6Ynr United nation recently showed the real face of india See what they said in report After knowing this I am sure you will hate them if you have soft heart https://youtu.be/oUskNtdWeIY https://youtu.be/oUskNtdWeIY Best way to get rid from face moles with the help of home remedies its easy and simple way You don't need to waste money for this https://zoomtips.blogspot.com/2019/05/easily-get-rid-from-face-moles-with.html https://zoomtips.blogspot.com/2019/05/easily-get-rid-from-fa...

icedchai 7y ago

I literally use dstat all the time! This is very sad.

op00to 7y ago
Why? What has changed? Do you use the plugin functionality of dstat, or do you just use the dstat command? If it's the latter, then you can do everything you could with dead-dstat and more with pcp-dstat.
- icedchai 7y ago
  It saddens me when a useful, good open source project closes. I realize I can still use it, and I will... That's not the point.

detaro 7y ago

redhat announcing their "new dstat": https://www.redhat.com/en/blog/implementing-dstat-performance-co-pilot https://www.redhat.com/en/blog/implementing-dstat-performanc...

astine 7y ago
The claim is that the original is no longer being maintained. Is that true? It changes a lot about what I would think of this move.
- codewiz 7y ago
  From the git changelog, it doesn't appear to be completely unmaintained, but not very vital either: https://github.com/dagwieers/dstat/commits/master https://github.com/dagwieers/dstat/commits/master Red Hat's announcement (posted in February 2019), also cites lack of Python 3 support as another reason for replacing the original dstat, but Python 3 compatibility was added last January.
  - loeg 7y ago
    pcp-dstat was implemented in 2018, FWIW. The blog post may have been written prior to the January 2019 dstat commits (before which the last commits were in 2016). More color: https://github.com/dagwieers/dstat/issues/156 https://github.com/dagwieers/dstat/issues/156
  - jsnell 7y ago
    The package was removed in Fedora 29, released October 2018.
    - dagwieers 7y ago
      Yes, and the plan to do this was conceived before June 2018.
  - dagwieers 7y ago
    Yeah, I added python 3 support after I learned that was the main reason for replacing it. It took me less than an hour to make it work on Python 3, including all (but 2) of the plugins. And given that PCP is using most of the original code, they must have made the same changes to get Python 3 support.

thisgoodlife 7y ago

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

type0 7y ago
It is the Big Gorilla, the silverback if you like. For other distros that would be even more confusing when some of their tools will be ported there.
pas 7y ago
The project was already dead. But now the maintainer[s] found time to complain about how evil RH simply opted to provide a py3 compatible replacement and provide it as dstat.
- dagwieers 7y ago
  That's not exactly what happened, but great to see you are making improvements in your fiction-writing skills :-) Keep it up !

deleted 7y ago

[deleted]

marktangotango 7y ago

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.

loeg 7y ago
That isn't Redhat's model. They open the code (it's mostly 3rd party OSS anyway), including packages (hence, CentOS) and sell access to the updates system and support contracts.
- lathiat 7y ago
  There's a couple of areas that's not actually true. For example their "insights" package which has rule based detection of problems to fix etc is open source but the actual ruleset is not.
- mindcrime 7y ago
  That isn't Redhat's model. Well... it hasn't been so far. But this isn't the old Red Hat anymore. This is IBM Hat. And for all the talk about keeping Red Hat mostly independent or whatever, I think we all know that's bullshit. Acquiring companies always give that little dog and pony show, and it never holds up in the long-term. There's no way that IBM culture won't wind up infecting Red Hat. Now whether that's a good thing or a bad thing is a question I'll leave to the philosophers. But I'd be very leery of assuming anything regarding what RH will or won't do going forward.
  - klohto 7y ago
    Every single thread someone has to bring it up. The acquisition isn’t even closed yet and suddenly every decision done is mysteriously pushed by IBM. There is more than enough people who have their own minds. That is the RH culture, if this freedom is touched they will just quit. IBM won’t affect RH in any way, Jim is not an idiot because he knows this would destroy RH and IBM are also not idiots because it would destroy they purchase.

snorrah 7y ago

Curious, i know dagwieers from being involved in the Ansible project (RedHat owned). Seems friction is occurring, given the language in his post.

dagwieers 7y ago
What language ? It is being quite factual really.
- sdiepend 7y ago
  Time to go to Puppet Dag? :)
  - fwdIT 7y ago
    :D

tedivm 7y ago

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. [1] https://github.com/dagwieers/dstat/issues/156 https://github.com/dagwieers/dstat/issues/156

deleted 7y ago
[deleted]
jsnell 7y ago
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.
- tmyklebu 7y ago
  What makes you think he misunderstood? What happens on fc30 when you 'yum install dstat' as he suggested? This webpage listing the contents of the fc30 pcp-system-tools package: https://fedora.pkgs.org/30/fedora-updates-x86_64/pcp-system-tools-4.3.2-1.fc30.x86_64.rpm.html https://fedora.pkgs.org/30/fedora-updates-x86_64/pcp-system-... lists a file called '/usr/bin/dstat'. The pcp-system-tools package obsoletes a package called 'dstat'. If you go to https://pkgs.org/download/dstat https://pkgs.org/download/dstat, and look under "Fedora 30," you get pcp-system-tools. [Spoiler: 'yum install dstat' installs pcp-system-tools, which has a symlink /usr/bin/dstat -> /usr/libexec/pcp/bin/pcp-dstat.]

proctor 7y ago

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." https://news.ycombinator.com/item?id=19935648 https://news.ycombinator.com/item?id=19935648

chubot 7y ago
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?
- bonzini 7y ago
  Not really, remember the ssh key fiasco which was also due to a Debian-only patch. (Disclaimer: I work for Red Hat)
- raverbashing 7y ago
  "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?
  - dagwieers 7y ago
    Is that what happened? I remember it differently...
- mattdm 7y ago
  Eh. Although we don't always do things perfectly, Fedora has a pretty strong policy of working with upstreams first. By contrast in my personal experience as a developer of something that got packaged in Debian, I discovered later that that package had a bunch of patches added, a man page written (!) and so on, none of which was bad, but also none of which was fed back to me at all. (In case not obvious: I work for Red Hat on Fedora.)

peterwwillis 7y ago

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?

cpitman 7y ago
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.
- user5994461 7y ago
  I'd say both stability and update. Debian never upgrades anything (unless security issue). All packages are frozen at the time of the initial major release. Have fun using curl/htop/nginx/libreoffice from 5-10 years ago, plenty of obscure bugs and missing command line flags. RHEL actually maintain their system packages.
jteppinette 7y ago
> which seems to be more common I have exclusively used the Fedora line in enterprise environments (CentOS, OEL, RHEL). The point about long term support is definitely #1.
protomyth 7y ago
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.

throw2016 7y ago

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.

dralley 7y ago
>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.
- throw2016 7y ago
  This is muddying the waters. Surely if you have gone through the trouble of looking at the repo and finding these pull requests you would also know the context and should then share it to give others here a context. Without that you are just here making 'vague' charges given dstat is a well known, highly regareded and mature tool. The Python3 port was already done by the author so the python2 eol seems a complete non sequitor. Again a rush to condemn without good reason. 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.

certik 7y ago

I submitted this PR long time ago: https://github.com/dagwieers/dstat/pull/50 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.

rurban 7y ago
You added a security problem. The fix is obvious for everybody working in security, but it's questionable if it should be discussed there.
- lstamour 7y ago
  I can see how the original CVE patch removed using the current working directory for loading plugins, but it seems like less of a security issue to simply look up one directory relative to the current binary install, assuming the binary is stored in ./bin after being built and plugins would be stored in ./shared ... Now, it might be inconsiderate to look up a folder when one could be preconfigured based on a common root or home folder, but it doesn’t necessarily seem as bad to trust the parent folder of a binary as trusting the current working directory’s contents?
  - Kalium 7y ago
    How do you arrive at the conclusion that looking at `./plugins/` is bad, but `../shared/dstat` is more acceptable? At first blush, the attack vector would seem to be exactly the same. Adding the extra layer of indirection does not seem, to my eyes, to add any significant extra layers of security. Both seem essentially untrustable from the perspective of the binary. Can you help me understand what I've missed in your explanation? I can also see where someone might not want to endlessly re-debate an old security decision.
    - lstamour 7y ago
      Sure. The original security bug was lines 31-32, but the new patch referring to the parent directory is a variation of line 30, untouched here: https://bugs.gentoo.org/attachment.cgi?id=210509&action=diff https://bugs.gentoo.org/attachment.cgi?id=210509&action=diff CWD is far worse a risk, because it changes every time the command is run. By comparison it could be assumed that a secure install of the software is in a trusted location, and this just gets the parent root of that location. Of course, it’s better if it’s documented, but I see no difference between this and $JAVA_HOME’s approach of ./bin, ./share, etc. It could be argued this is better—no environment variables can override the default. If you install the app to /tmp/bin that’s your own fault...

rurban 7y ago

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 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597050

JdeBP 7y ago
This sort of thing happens regularly. For another example of many, witness the effects on users of the change of the "mailx" command in Debian. * https://unix.stackexchange.com/q/469780/5132 https://unix.stackexchange.com/q/469780/5132 * https://unix.stackexchange.com/q/489477/5132 https://unix.stackexchange.com/q/489477/5132

gigatexal 7y ago

Why not come up with a new name for the project instead of rage quitting?

anthony_doan 7y ago
> 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?
- gigatexal 7y ago
  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.
  - ben0x539 7y ago
    Would redhat ship dstat under the new name?
    - gigatexal 7y ago
      They should have shipped the original devs version or forked it and worked with him to get it supported and submitted their RH changes upstream etc.
  - anthony_doan 7y ago
    > It’s the idea of turning the other cheek. I had to look this up. > refrain from retaliating when one has been attacked or insulted. I don't think he have retaliated in anyway, at least from the github commit message and the blog post. He just decided it wasn't worth his free time to deal with this problem. Maybe there is a disagreement with the definition of rage quitting but it was his open source project and his free time. I don't think it's rage quitting if he wants to quit and do something else with his free time. Rage quitting have a negative connotation such as flipping table or that scene from the movie Half baked where the dude cussed everybody out before quitting. He seems to have a career, whether you care or not, labeling at such may be detrimental to his career. Regardless of if you care or not, I hope other people refrain from speculating or do huge leaps of conclusion base on little or no facts that can damage other people's ability to make a living.

clhodapp 7y ago

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.

zonidjan 7y ago
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".
- deleted 7y ago
  [deleted]
- JdeBP 7y ago
  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 https://unix.stackexchange.com/a/508142/5132 * http://jdebp.uk./FGA/inittab-getty-is-history.html http://jdebp.uk./FGA/inittab-getty-is-history.html * https://news.ycombinator.com/item?id=19988382 https://news.ycombinator.com/item?id=19988382 * https://news.ycombinator.com/item?id=17005677 https://news.ycombinator.com/item?id=17005677 * https://unix.stackexchange.com/a/316279/5132 https://unix.stackexchange.com/a/316279/5132

mattdm 7y ago

So, from a Fedora Project point of view, I'm not really sure how we could have done this better. This change was properly announced and publicized as https://fedoraproject.org/wiki/Changes/MergeDstatAndPerformanceCoPilot https://fedoraproject.org/wiki/Changes/MergeDstatAndPerforma... and approved by FESCo (the Fedora Engineering Steering Committee) in August 2018 (https://pagure.io/fesco/issue/1956 https://pagure.io/fesco/issue/1956). 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 7y ago
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.”

rain1 7y ago

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.