31–40 of 159 posts
Earlier quoted context omitted.
To contrast, Redhat's pcp dstat looks like it was mostly developed during 2018 (a period during which dstat had been totally inactive for 2-3 years): https://github.com/performancecopilot/pcp/commits/master/src...
oh god. it's based on pcp o.O
Earlier quoted context omitted.
GitHub PRs being ignored seems totally true. https://github.com/dagwieers/dstat/pulls?q=is%3Apr+is%3Aclos...
Which PRs are you talking about? PRs I see there are either all from the last 4 hours or from 2016 and earlier that were merged.
I literally use dstat all the time! This is very sad.
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.
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.
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
Maybe Debian is more respectful since it's open source not backed by a company with enterprise customers?
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…
Earlier quoted context omitted.
Which PRs are you talking about? PRs I see there are either all from the last 4 hours or from 2016 and earlier that were merged.
4 hours ago was the last update to the PR, the pull requests are from years ago.
Earlier quoted context omitted.
GitHub PRs being ignored seems totally true. https://github.com/dagwieers/dstat/pulls?q=is%3Apr+is%3Aclos...
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.
>>> 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?
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?
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.