141–150 of 159 posts
Earlier quoted context omitted.
Are all of those people commenting Red Hat employees ?
Well, I am at least. I care about when things like this happen, including figuring out how we can do better.
Earlier quoted context omitted.
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 MiB
Possible options: 1. Some of mercurial's bundled plugins are not Py3 compatible (I recall reading a discussion as an outsider a while back that some plugins are planned to be ported to Rust, not Python 3, but that may have changed) 2. Nobody involved in packaging it for Arch has had time to verify mercurial 5 on python 3.
Earlier quoted context omitted.
Well, I am at least. I care about when things like this happen, including figuring out how we can do better.
Start by fixing this issue- make it so `yum install dstat` installs the real dstat program.
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?
Earlier quoted context omitted.
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?
Actually, yes they did. The use of /sbin/init was something that came up during the Debian Hoo-Hah. The conclusion was that it should be a symbolic link, and that there should be distinct packages providing that link and providing the real executable program image file that it points to. * https://packages.debian.org/search?suite=jessie&searchon=con...
Earlier quoted context omitted.
They install a symlink from plain "dstat" to pcp-dstat. That's the exact same name part and plausibly objectionable.
The entire principle of a GNU based system is that everything is a reimplementation of original Unix tools with the same names but different provenances.
Earlier quoted context omitted.
> 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.
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.
Earlier quoted context omitted.
Possible options: 1. Some of mercurial's bundled plugins are not Py3 compatible (I recall reading a discussion as an outsider a while back that some plugins are planned to be ported to Rust, not Python 3, but that may have changed) 2. Nobody involved in packaging it for Arch has had time to verify mercurial 5 on python 3.
So looking into this a bit more (and my edit window has expired), it's because the mercurial team themselves suggest not to package mercurial 5.0 for python 3 yet: https://www.mercurial-scm.org/wiki/Release5.0
Earlier 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], ...
Arch doesn't promise support. Red Hat does. If software in Arch is unsupported in the near future but currently works, that's less of a problem than software in RHEL becoming definitely unsupported during the release lifetime.