5 ms·

[Disclosure: I'm a long-term Red Hatter.] Hmm. That's painful indeed. Sorry that you had such a dispiriting experience with the 'procps' package. For what

[Disclosure: I'm a long-term Red Hatter.] Hmm. That's painful indeed. Sorry that you had such a dispiriting experience with the 'procps' package. For what it's worth, allow me to share my experience (I joined after 2008; so I can only speak about that period onwards) of being at Red Hat. One of the reasons that keep me at Red Hat is the iron-clad (with some sensible exceptions, e.g. security embargoes) principle of Upstream First. I see every day (and the community can verify -- the source out it there) maintainers upholding that value. And I've seen several times over the years maintainers, including yours truly, vigorously reject requests of 'downstream-only' patches or other deviations from upstream. When there are occasional exceptions, they need extraordinary justifications; either that, or those downstream patches are irrelevant in context of upstream. I've learnt enormously from observing inspiring maintainers at Red Hat (many are also upstream maintainers) on how to do the delicate Tango of balancing the upstream vs. downstream hats. So if it's any consolation, please know that for every aberration, there are thousands of other packages that cooperate peacefully with relevant upstreams.

kashyapc 7y ago
> the source out it there [Typo: "out it there --> "is out there"]
loqd 7y ago
Some of RedHat's dual upstream/downstream maintainers are possessively trying to take over the upstream projects while not doing very important changes. Others are great human beings. But on the whole, RedHat skepticism is healthy (this also applies to the NIH software that they push onto most Linux distributions).
- Diederich 7y ago
  > NIH software that they push onto most Linux distributions This is likely off topic, but can you expand on that if you have a moment? Thanks.
  - inferiorhuman 7y ago
    Systemd comes to mind.
  - nine_k 7y ago
    Before systemd, there was pulseaudio.
souprock 7y ago
A bit more detail on some Red Hat experiences: I had reserved -M for security labels, to be compatible with Trusted Irix, and I think this was clear in the source code at the time. I intended to avoid any additional library dependency if possible, because ps is a critical tool that must not break. If I couldn't manage without a weird SELinux library, then I'd dlopen() it only if needed. Red Hat swiped both -Z and Z, giving them the same meaning. For at least one of those, probably -Z but this was a long time ago, my plans were to use it for being compatible with a different feature of another OS. There are only 52 possible command option letters, not counting weirdness like non-ASCII and punctuation, and most are already taken. Now 3 of them, almost 6% of the possible space, are redundantly dedicated to an obscure feature. An added annoyance was that -Z got wrongly thrown into ps's list of POSIX-standard options, which can affect parsing in subtle ways. One day I discovered this as it was being shipped in RHEL. A more recent and amusing issue is with the recent storm of security bugs that hit procps. They actually predate my involvement with procps, likely going all the way back to the early 1990s. I ended up getting notice. I responded on the Bugzilla, correcting some misunderstandings and pointing out better ways to fix the problems. I even do software security work these days, professionally, so I would be the ultimate expert on security bug fixes for procps. My helpfulness got me blocked from looking at the Bugzilla and then Red Hat proceeded to ship slightly bone-headed patches for the security problems. BTW, last I checked there were still DoS vulnerabilities because Red Hat ignored my advice. Turning the 32-bit value into a 64-bit value may prevent an integer wrap-around exploit, but that just means the system will swap until the OOM killer strikes. The value should have stayed 32-bit, with protection added to avoid even approaching such a large value. You probably don't even need more than 17-bit. The stuff with escape expansion is also bad, differently. Instead of papering over the problem, the math should have been corrected.

kashyapc 7y ago

> the source out it there [Typo: "out it there --> "is out there"]

loqd 7y ago

Some of RedHat's dual upstream/downstream maintainers are possessively trying to take over the upstream projects while not doing very important changes. Others are great human beings. But on the whole, RedHat skepticism is healthy (this also applies to the NIH software that they push onto most Linux distributions).

Diederich 7y ago
> NIH software that they push onto most Linux distributions This is likely off topic, but can you expand on that if you have a moment? Thanks.
- inferiorhuman 7y ago
  Systemd comes to mind.
- nine_k 7y ago
  Before systemd, there was pulseaudio.

souprock 7y ago

A bit more detail on some Red Hat experiences: I had reserved -M for security labels, to be compatible with Trusted Irix, and I think this was clear in the source code at the time. I intended to avoid any additional library dependency if possible, because ps is a critical tool that must not break. If I couldn't manage without a weird SELinux library, then I'd dlopen() it only if needed. Red Hat swiped both -Z and Z, giving them the same meaning. For at least one of those, probably -Z but this was a long time ago, my plans were to use it for being compatible with a different feature of another OS. There are only 52 possible command option letters, not counting weirdness like non-ASCII and punctuation, and most are already taken. Now 3 of them, almost 6% of the possible space, are redundantly dedicated to an obscure feature. An added annoyance was that -Z got wrongly thrown into ps's list of POSIX-standard options, which can affect parsing in subtle ways. One day I discovered this as it was being shipped in RHEL. A more recent and amusing issue is with the recent storm of security bugs that hit procps. They actually predate my involvement with procps, likely going all the way back to the early 1990s. I ended up getting notice. I responded on the Bugzilla, correcting some misunderstandings and pointing out better ways to fix the problems. I even do software security work these days, professionally, so I would be the ultimate expert on security bug fixes for procps. My helpfulness got me blocked from looking at the Bugzilla and then Red Hat proceeded to ship slightly bone-headed patches for the security problems. BTW, last I checked there were still DoS vulnerabilities because Red Hat ignored my advice. Turning the 32-bit value into a 64-bit value may prevent an integer wrap-around exploit, but that just means the system will swap until the OOM killer strikes. The value should have stayed 32-bit, with protection added to avoid even approaching such a large value. You probably don't even need more than 17-bit. The stuff with escape expansion is also bad, differently. Instead of papering over the problem, the math should have been corrected.