Discussion:
Proposal: add "--disable-modern-top" to procps-ng configure flags
(too old to reply)
Jonathon Fernyhough
2017-12-09 15:39:46 UTC
Permalink
# Background

procps-ng [1] introduced a new default interface layout for `top` with
version 3.3.10 which switched the "traditional" list display of
processes ordered by CPU usage to a red text-based tree of processes
ordered by PID (with root on 'systemd').


# Rationale

The "modern" default interface:

* requires user configuration to make usable;
* uses low-contrast text;
* is not consistent with other distros;
* has caused confusion to Arch users [2].

This change would:

* make `top` usable by default;
* make `top` more accessible by default (high contrast text);
* ease transition for new Arch users;
* maintain consistency of a 'base' tool behaviour with other distros.


# Precedent

'--disable-modern-top' is used by Debian [3] and Fedora [4] (and hence
all derivative distros).


# Change

See PKGBUILD attachment at
https://bugs.archlinux.org/task/56639?getfile=15944


# Impact of change

Default interface is reverted to "traditional" display. No effect on
functionality or users with existing .toprc. Comparison screenshots are
available on the Manjaro forum thread [5].

# Maintenance burden

None beyond change to configure flag in PKGBUILD.


# Links

[1] https://gitlab.com/procps-ng/procps
[2] https://bbs.archlinux.org/viewtopic.php?id=189757
[3]
https://anonscm.debian.org/cgit/collab-maint/procps.git/tree/debian/rules#n37
[4]
https://src.fedoraproject.org/rpms/procps-ng/blob/master/f/procps-ng.spec#_113
[5]
https://forum.manjaro.org/t/new-procps-ng-with-traditional-top-display/36119
Doug Newgard via arch-general
2017-12-09 16:21:41 UTC
Permalink
On Sat, 9 Dec 2017 15:39:46 +0000
Post by Jonathon Fernyhough
* requires user configuration to make usable;
Completely subjective
Post by Jonathon Fernyhough
* uses low-contrast text;
So? This is personal preference
Post by Jonathon Fernyhough
* is not consistent with other distros;
Nobody cares
Post by Jonathon Fernyhough
* has caused confusion to Arch users [2].
Nobody cares


What you have left out is that your proposal has already been rejected
(https://bugs.archlinux.org/task/56639). Complaining in every venue you can
find does nothing other than make people ignore you in the future.
Jonathon Fernyhough
2017-12-09 16:31:21 UTC
Permalink
Post by Doug Newgard via arch-general
On Sat, 9 Dec 2017 15:39:46 +0000
Post by Jonathon Fernyhough
* requires user configuration to make usable;
Completely subjective
Post by Jonathon Fernyhough
* uses low-contrast text;
So? This is personal preference
Post by Jonathon Fernyhough
* is not consistent with other distros;
Nobody cares
Post by Jonathon Fernyhough
* has caused confusion to Arch users [2].
Nobody cares
What you have left out is that your proposal has already been rejected
(https://bugs.archlinux.org/task/56639). Complaining in every venue you can
find does nothing other than make people ignore you in the future.
I thought that a more fully-formed proposal with more detailed rationale
sent to the mailing list where devs might read it might have made the
case better, but if that's "complaining" then I guess I really don't
understand how you do things.

Thanks for spending the time to consider the proposal and for your
valuable input, nevertheless.

If anyone is willing to help me contribute in a way that isn't viewed as
"complaining" please point me in the right direction.


J
Doug Newgard via arch-general
2017-12-09 16:55:51 UTC
Permalink
On Sat, 9 Dec 2017 16:31:21 +0000
Post by Jonathon Fernyhough
If anyone is willing to help me contribute in a way that isn't viewed as
"complaining" please point me in the right direction.
And now you're asking how to complain without it being viewed as complaining.
The decision was made, move on unless you have a compelling argument you
haven't brought yet. Contributing is fine, harping on something that's already
decided and done (2 years ago!) is not contributing.
Doug Newgard via arch-general
2017-12-09 17:06:11 UTC
Permalink
On Sat, 9 Dec 2017 10:55:51 -0600
Post by Doug Newgard via arch-general
On Sat, 9 Dec 2017 16:31:21 +0000
Post by Jonathon Fernyhough
If anyone is willing to help me contribute in a way that isn't viewed as
"complaining" please point me in the right direction.
And now you're asking how to complain without it being viewed as complaining.
The decision was made, move on unless you have a compelling argument you
haven't brought yet. Contributing is fine, harping on something that's already
decided and done (2 years ago!) is not contributing.
Correction, that should be 3 years ago.
Jonathon Fernyhough
2017-12-09 17:19:22 UTC
Permalink
Post by Doug Newgard via arch-general
On Sat, 9 Dec 2017 16:31:21 +0000
Post by Jonathon Fernyhough
If anyone is willing to help me contribute in a way that isn't viewed as
"complaining" please point me in the right direction.
And now you're asking how to complain without it being viewed as complaining.
The decision was made, move on unless you have a compelling argument you
haven't brought yet. Contributing is fine, harping on something that's already
decided and done (2 years ago!) is not contributing.
No, I was asking how to propose changes without it being viewed as
complaining.

Just because something was "done" two years ago doesn't mean there's not
a better way of doing it.

I've already said why I posted to the list; I can't see why that's
"harping on about it" and this just comes across as "patronizing" on
your part. So fine, I'm not an Arch user or dev - but so what? Do you
want me to quote your own Code of Conduct here? I assume it's not just
"because Manjaro" as that would be counter-productive for everyone.

As far as this issue goes, I'm happy to leave it that the Arch devs
aren't interested in making the change, as apparently there is zero
merit in the proposal, despite `top` currently not honouring terminal
colour settings and so being inaccessible. Even if there were any merit,
any change now would undermine the hard-line position you've taken.


J
Ralf Mardorf
2017-12-09 17:31:12 UTC
Permalink
Post by Jonathon Fernyhough
Just because something was "done" two years ago doesn't mean there's
not a better way of doing it.
I guess you read [1] and [2]. As a side note, don't worry about the
out-of-date flag from yesterday. IIRC procps-ng-classic from AUR never
caused an issue, at least I can't comment the 3 comments at
https://aur.archlinux.org/packages/procps-ng-classic/ .

[1]
https://lists.archlinux.org/pipermail/arch-general/2017-December/044497.html
Post by Jonathon Fernyhough
In this particular case, ask upstream (as also pointed out on the bug
tracker). Arch Linux does not patch software or deviate from its
default behaviour unless absolutely necessary (usually in case of bugs
that make an application unusable).
[snip]
Don't try to discuss Arch Linux packaging decisions. There is nothing
you can really do. The least frustrating approach is to simply package
stuff your own and fix the things that annoy you (and from what I see,
you're already doing that).
[2]
https://lists.archlinux.org/pipermail/arch-general/2017-December/044496.html
Post by Jonathon Fernyhough
I'm using procps-ng-classic from AUR since 2014.
[snip]
Jonathon Fernyhough
2017-12-09 17:47:19 UTC
Permalink
Post by Ralf Mardorf
Post by Jonathon Fernyhough
Just because something was "done" two years ago doesn't mean there's
not a better way of doing it.
I guess you read [1] and [2].
Yes.

Two people reply to the list who use or package their own alternative
version because of the aggro of suggesting changes to packages when,
e.g., upstream might not care or upstream's decisions might not be a
one-size-fits-all.

While this is devolving into
https://wiki.archlinux.org/index.php/Code_of_conduct#Ineffective_discussion_.28.22bikeshed.22.29,
if people are actually afraid to post I'd suggest that might be
something to look at.


J

(Yes, I'm done now ;)
Ralf Mardorf
2017-12-09 18:08:49 UTC
Permalink
Post by Jonathon Fernyhough
Post by Ralf Mardorf
Post by Jonathon Fernyhough
Just because something was "done" two years ago doesn't mean there's
not a better way of doing it.
I guess you read [1] and [2].
Yes.
Two people reply to the list who use or package their own alternative
version because of the aggro of suggesting changes to packages when,
e.g., upstream might not care or upstream's decisions might not be a
one-size-fits-all.
While this is devolving into
https://wiki.archlinux.org/index.php/Code_of_conduct#Ineffective_discussion_.28.22bikeshed.22.29,
if people are actually afraid to post I'd suggest that might be
something to look at.
J
(Yes, I'm done now ;)
As already pointed out off-list. Take things with a good sense of black
humour! C'mon! It's nearly impossible to find a more useless default,
than the PID 1 systemd tree and without the slightest doubt everybody is
aware of this.
Eli Schwartz via arch-general
2017-12-09 23:36:10 UTC
Permalink
Post by Jonathon Fernyhough
No, I was asking how to propose changes without it being viewed as
complaining.
You proposed changes after three years of an *upstream* default, when
Arch is a distro designed around the philosophy of packaging *upstream*
code, and when the appropriate response is to either:
1) Convince upstream their default sucks. Because the default does
indeed suck,
2) Spread the word to all and sundry, that the default sucks, hopefully
eventually the procps-ng maintainers will realize there is nothing
"modern" about this.
3) Come to the sneaking realization that, yes, top sucks, but not just
because of this -- and ditch top for htop. Because top sucks, and
--disable-modern-top will not fix that.
Post by Jonathon Fernyhough
So fine, I'm not an Arch user or dev - but so what? Do you
want me to quote your own Code of Conduct here? I assume it's not just
"because Manjaro" as that would be counter-productive for everyone.
We're generally fine with "I'm not a Dev", where do you think TUs
eventually come from? People who contribute with ideas, help,
infrastructure suggestions, etc. Griping about a rather obviously
subjective *policy* decision is not, however, a "change", it's a
political request that assumes everyone agrees with you about how top
"should" look (and clearly some people like it, or even upstream
wouldn't support it).

Mind you, we didn't realize you were a Manjaro user. So you have another
option too -- ask Manjaro to override our package with their own, since
naturally Manjaro as a "value-added Arch derivative for beginners" would
want to validate their existence by, well, adding value for beginners.
Post by Jonathon Fernyhough
As far as this issue goes, I'm happy to leave it that the Arch devs
aren't interested in making the change, as apparently there is zero
merit in the proposal, despite `top` currently not honouring terminal
colour settings and so being inaccessible. Even if there were any merit,
any change now would undermine the hard-line position you've taken.
htop is *very* accessible, consider trying it. :)
--
Eli Schwartz
Jonathon Fernyhough
2017-12-10 00:10:15 UTC
Permalink
Post by Eli Schwartz via arch-general
You proposed changes after three years of an *upstream* default, when
Arch is a distro designed around the philosophy of packaging *upstream*
1) Convince upstream their default sucks. Because the default does
indeed suck,
2) Spread the word to all and sundry, that the default sucks, hopefully
eventually the procps-ng maintainers will realize there is nothing
"modern" about this.
3) Come to the sneaking realization that, yes, top sucks, but not just
because of this -- and ditch top for htop. Because top sucks, and
--disable-modern-top will not fix that.
If there's a single configure flag (as already used by two large distros
and derivatives) that makes `top` suck "less" surely that's also an
option - especially if the default is _known_ to suck and the upstream
project did it on purpose.

Yes - they changed the default to try and force people to read the
documentation. Most people just switched to `htop` instead [citation
needed].
Post by Eli Schwartz via arch-general
We're generally fine with "I'm not a Dev", where do you think TUs
eventually come from? People who contribute with ideas, help,
infrastructure suggestions, etc. Griping about a rather obviously
subjective *policy* decision is not, however, a "change", it's a
political request that assumes everyone agrees with you about how top
"should" look (and clearly some people like it, or even upstream
wouldn't support it).
I submitted, what I thought, was a reasonably structured and detailed
proposal to change one flag in a PKGBUILD file which would have few (if
any) side effects.

The whole point of a proposal is to drive a discussion; there is no
assumption it is absolutely correct. I don't see that as "griping". If
I'd just said "top sucks, you should fix it", then fine - but I didn't
do that.
Post by Eli Schwartz via arch-general
Mind you, we didn't realize you were a Manjaro user.
I assumed my email address might be a giveaway.
Post by Eli Schwartz via arch-general
So you have another option too -- ask Manjaro to override our package with their own, since
naturally Manjaro as a "value-added Arch derivative for beginners" would
want to validate their existence by, well, adding value for beginners.
I've already released an updated package (as per link [5] in my OP). As
I said somewhere else (maybe on the Arch forum?), if raising changes
"upstream" can benefit the whole ecosystem it's worth doing.

I'd probably dispute the "for beginners" bit though... ;) Plus, we
really don't need to validate our existence, thank you.


J
Eli Schwartz via arch-general
2017-12-10 00:27:02 UTC
Permalink
Post by Jonathon Fernyhough
If there's a single configure flag (as already used by two large distros
and derivatives) that makes `top` suck "less" surely that's also an
option - especially if the default is _known_ to suck and the upstream
project did it on purpose.
Yes - they changed the default to try and force people to read the
documentation. Most people just switched to `htop` instead [citation
needed].
I certainly switched to htop as a response, but I made no claim about
anyone else...
Post by Jonathon Fernyhough
I submitted, what I thought, was a reasonably structured and detailed
proposal to change one flag in a PKGBUILD file which would have few (if
any) side effects.
Adding extraneous flags as a political decision to deviate from upstream
defaults is itself a side effect. We will not do this without
significantly more justification than "I dislike how it looks and don't
want to write my own config file". In the truest spirit of Arch Linux,
we would like "defaults suck and no one can read this garbage" to be
fixed upstream, while Arch users will likely read the manpage and set
their own configuration (though I personally encourage switching to
htop, which not only fixed my gripe with top, but turned out to be the
process viewer I hadn't realized I was missing).
Post by Jonathon Fernyhough
The whole point of a proposal is to drive a discussion; there is no
assumption it is absolutely correct. I don't see that as "griping". If
I'd just said "top sucks, you should fix it", then fine - but I didn't
do that.
You said "top sucks, let me list the reasons why I don't like it". This
is no better!

Turning a gripe into a bulleted list of gripes does not constitute
migrating from a gripe to a "proposal"; being a "proposal" says nothing
whatsoever about its status as a technical merit vs. political change.

So we'd have to look at the *content* of your proposal... and there we
hit into the issue that you just responded to by claiming that "OMG it's
a proposal not a gripe" without actually saying anything.

Namely, you agree it is subjective but want to argue about whether
everyone agrees with your subjective opinion. But... Arch does not and
never has and never will care about peoples' subjective opinions merely
for the sake of subjective opinions. We expect people to read manpages
and configure software for themselves. We don't add changes to upstream
except for clearly defined reasons, and configuring things on behalf of
the user is not one of these reasons.

So excuse me, but in what possible world did you either file that
bugreport or start this discussion thread with the belief that you had
any chance whatsoever of getting this changed? This whole issue
approaches the level of a deliberate spam comment... and given that you
are *that* jonathon, I am not going to buy ignorance as an excuse.
Post by Jonathon Fernyhough
Post by Eli Schwartz via arch-general
Mind you, we didn't realize you were a Manjaro user.
I assumed my email address might be a giveaway.
Guilty! I only looked at your email address after I sent the email.
Post by Jonathon Fernyhough
Post by Eli Schwartz via arch-general
So you have another option too -- ask Manjaro to override our package with their own, since
naturally Manjaro as a "value-added Arch derivative for beginners" would
want to validate their existence by, well, adding value for beginners.
I've already released an updated package (as per link [5] in my OP). As
I said somewhere else (maybe on the Arch forum?), if raising changes
"upstream" can benefit the whole ecosystem it's worth doing.
I'd probably dispute the "for beginners" bit though... ;) Plus, we
really don't need to validate our existence, thank you.
Awesome! So happy that a mutually satisfactory outcome was obtained!

Now why does this mailing list thread exist...
--
Eli Schwartz
Jonathon Fernyhough
2017-12-10 01:00:25 UTC
Permalink
Post by Eli Schwartz via arch-general
Adding extraneous flags as a political decision to deviate from upstream
defaults is itself a side effect. We will not do this without
significantly more justification than "I dislike how it looks and don't
want to write my own config file". In the truest spirit of Arch Linux,
we would like "defaults suck and no one can read this garbage" to be
fixed upstream, while Arch users will likely read the manpage and set
their own configuration (though I personally encourage switching to
htop, which not only fixed my gripe with top, but turned out to be the
process viewer I hadn't realized I was missing).
I thought that e.g. accessibility and user experience was greater
justification than "I dislike it". Granted it's not the raison d'etre of
Arch but with such a small commitment/maintenance burden I honestly
couldn't see the harm in it. If I could I wouldn't have bothered with
any of this.
Post by Eli Schwartz via arch-general
You said "top sucks, let me list the reasons why I don't like it". This
is no better!
Turning a gripe into a bulleted list of gripes does not constitute
migrating from a gripe to a "proposal"; being a "proposal" says nothing
whatsoever about its status as a technical merit vs. political change.
Providing an implementation with rationale (whether or not you agree
with it) is definitely not "griping".

If someone submitted a PR which changed code you wouldn't call it
political. This is no different.
Post by Eli Schwartz via arch-general
So we'd have to look at the *content* of your proposal... and there we
hit into the issue that you just responded to by claiming that "OMG it's
a proposal not a gripe" without actually saying anything.
I don't know what else you want. I remember (in another life) someone
saying "unless someone has a substantive reason", which really meant
"unless there's something involving money". Anything else wasn't "valid".

In this case... I don't honestly know. What could/should have been a
quick discussion has moved into what's approaching a philosophical
discussion, which certainly wasn't my intention.
Post by Eli Schwartz via arch-general
Namely, you agree it is subjective but want to argue about whether
everyone agrees with your subjective opinion. But... Arch does not and
never has and never will care about peoples' subjective opinions merely
for the sake of subjective opinions. We expect people to read manpages
and configure software for themselves. We don't add changes to upstream
except for clearly defined reasons, and configuring things on behalf of
the user is not one of these reasons.
So excuse me, but in what possible world did you either file that
bugreport or start this discussion thread with the belief that you had
any chance whatsoever of getting this changed? This whole issue
approaches the level of a deliberate spam comment...
"If you have a question regarding Arch development, please ensure that
your topic poses a specific question and be open-minded to responses. If
possible, provide a solution or partial solution. Submitting code and
patches for discussion is always more pragmatic than asking others to do
it for you."
Post by Eli Schwartz via arch-general
and given that you are *that* jonathon, I am not going to buy ignorance as an excuse.
Thank you.
Post by Eli Schwartz via arch-general
Awesome! So happy that a mutually satisfactory outcome was obtained!
I'm glad the discussion was productive, sarcasm aside.


J
Doug Newgard via arch-general
2017-12-10 03:27:49 UTC
Permalink
On Sun, 10 Dec 2017 00:10:15 +0000
Post by Jonathon Fernyhough
I submitted, what I thought, was a reasonably structured and detailed
proposal to change one flag in a PKGBUILD file which would have few (if
any) side effects.
The whole point of a proposal is to drive a discussion; there is no
assumption it is absolutely correct. I don't see that as "griping". If
I'd just said "top sucks, you should fix it", then fine - but I didn't
do that.
To be clear, the real issue people are having with you here isn't your
proposal. It's the fact that you submitted it to the bug tracker, the
maintainer saw it, thought about it, and rejected it, but you couldn't let it
go at that. You instead drew out a forum thread to the point it got closed,
then decided to continue here. That is not the behavior of someone who wants
discussion or to contribute, it's the behavior of someone trying to cause
trouble. It comes across as petty and whiny. Please remember this for future
interactions.
Leonid Isaev via arch-general
2017-12-10 03:38:30 UTC
Permalink
Post by Doug Newgard via arch-general
On Sun, 10 Dec 2017 00:10:15 +0000
Post by Jonathon Fernyhough
I submitted, what I thought, was a reasonably structured and detailed
proposal to change one flag in a PKGBUILD file which would have few (if
any) side effects.
The whole point of a proposal is to drive a discussion; there is no
assumption it is absolutely correct. I don't see that as "griping". If
I'd just said "top sucks, you should fix it", then fine - but I didn't
do that.
To be clear, the real issue people are having with you here isn't your
proposal. It's the fact that you submitted it to the bug tracker, the
maintainer saw it, thought about it, and rejected it...
In general, discussions about defaults are silly, as long as things are
configurable at run-time, so I don't understand why that bugreport was accepted
at all...

Cheers,
--
Leonid Isaev
Jonathon Fernyhough
2017-12-10 11:33:44 UTC
Permalink
Post by Doug Newgard via arch-general
To be clear, the real issue people are having with you here isn't your
proposal. It's the fact that you submitted it to the bug tracker, the
maintainer saw it, thought about it, and rejected it, but you couldn't let it
go at that. You instead drew out a forum thread to the point it got closed,
then decided to continue here. That is not the behavior of someone who wants
discussion or to contribute, it's the behavior of someone trying to cause
trouble. It comes across as petty and whiny. Please remember this for future
interactions.
I think you're re-framing the timeline here, possibly showing that your
view of events was influenced by your view of me "trying to cause
trouble". I was told the forum is a separate entity which devs don't
read, hence it was pointless discussing this there. I've already said
why I sent to list after the bug report was closed.

I don't think I have been disrespectful to anyone in this entire
exchange, and have answered or responded to points raised during the
discussion. I made one tangential post in response to what seems to be
people's fears of posting.

But, point taken: I shall remember these events for future interactions.


J
Ralf Mardorf
2017-12-09 17:00:01 UTC
Permalink
I'm using procps-ng-classic from AUR since 2014.

[***@archlinux ~]$ yaourt -Ss $(pacman -Qo /usr/bin/top | awk '{print $5}')
aur/procps-ng-classic 3.3.11-1 [installed] (Out of Date) (3) (0.00)
Utilities for monitoring your system and its processes (with classic top)
[***@archlinux ~]$ grep -m1 procps-ng-classic /var/log/pacman.log | awk '{print $1}'
[2014-11-19
Tinu Weber
2017-12-09 17:05:14 UTC
Permalink
Post by Jonathon Fernyhough
If anyone is willing to help me contribute in a way that isn't viewed as
"complaining" please point me in the right direction.
In this particular case, ask upstream (as also pointed out on the bug
tracker). Arch Linux does not patch software or deviate from its default
behaviour unless absolutely necessary (usually in case of bugs that make
an application unusable).

Also, from what I have seen, even Debian and Fedora eventually go with
upstream for these kinds of changes (at least that was the case for the
`ls` output style in coreutils >=8.25 - Debian users only recently also
got to see the super-cool new default for --quoting-style).

An personal advice from my side, as I have also been burnt by that:
Don't try to discuss Arch Linux packaging decisions. There is nothing
you can really do. The least frustrating approach is to simply package
stuff your own and fix the things that annoy you (and from what I see,
you're already doing that).

Best,
Tinu
Gaetan Bisson via arch-general
2017-12-09 19:55:14 UTC
Permalink
Post by Jonathon Fernyhough
Thanks for spending the time to consider the proposal and for your
valuable input, nevertheless.
Your sarcasm is really pissing me off because I did take the time to
review your bug report before replying with my analysis and two
constructive suggestions for you. Let me recall them to you:

Just write a `.toprc` to enforce your favorite options; problem
solved. And if you really feel strongly about the new interface
not matching your definition of "progress" you should bring your
suggestions upstream.

And what did you do with this "valuable input"? Conveniently ignored it
so you could go on ranting and trying to rally people to your "cause".
Guess what? That's not how change happens in open source circles, that's
just a way to piss people off and make them ignore your future requests.

So if you're serious about change start coding already and send pull
requests upstream.
--
Gaetan
Jonathon Fernyhough
2017-12-09 20:12:23 UTC
Permalink
Post by Gaetan Bisson via arch-general
Post by Jonathon Fernyhough
Thanks for spending the time to consider the proposal and for your
valuable input, nevertheless.
Your sarcasm
There was actually no sarcasm intended there - I really was thanking him
for spending his time on it.
Post by Gaetan Bisson via arch-general
So if you're serious about change start coding already and send pull
requests upstream.
I did that - I researched, tested, and submitted a change to the
packaging file. In this particular instance it would represent a change
to the packaging files, not upstream code.


J
Felix Yan via arch-general
2017-12-09 20:43:00 UTC
Permalink
Post by Jonathon Fernyhough
* requires user configuration to make usable;
* uses low-contrast text;
<snip>
Post by Jonathon Fernyhough
I did that - I researched, tested, and submitted a change to the
packaging file. In this particular instance it would represent a change
to the packaging files, not upstream code.
The two claims are about upstream code, though. I didn't find reports
about these on the procps-ng issue tracker. Please describe your
specific problem there.
--
Regards,
Felix Yan
Jonathon Fernyhough
2017-12-09 20:59:51 UTC
Permalink
Please describe your specific problem there.
Done: https://gitlab.com/procps-ng/procps/issues/78

J
Jonathon Fernyhough
2017-12-09 21:19:56 UTC
Permalink
Post by Jonathon Fernyhough
https://gitlab.com/procps-ng/procps/issues/78
For info, marked as dupe of
https://gitlab.com/procps-ng/procps/issues/6, the first reply of which
Post by Jonathon Fernyhough
Anyway, packagers have the option to preserve the old top defaults at build time, which Fedora has done. Archlinux appears to offer an alternate 'classic' top version too.
I presume the "alternate" mentioned is the AUR package already pointed out.

So, it comes down to a packaging decision which has already been made.
As this isn't going to change I'll let you good folks get back to your
Saturday. :)


J
Ralf Mardorf
2017-12-09 21:31:04 UTC
Permalink
Post by Jonathon Fernyhough
I presume the "alternate" mentioned is the AUR package already pointed out.
So, it comes down to a packaging decision which has already been made.
As this isn't going to change I'll let you good folks get back to your
Saturday. :)
It is and I like to notice that you are seemingly able to take it with
a dry sense of humour, too :).
Saul Reynolds-Haertle via arch-general
2017-12-09 22:04:33 UTC
Permalink
Apologies if this is misformatted, and I hope it works; I didn't
expect to be responding and am working in the system optimized for
readability over composition.

I subscribed to this list just last night in hopes of gaining better
visibility into the tools that I use. I have, and I think that I
should report my findings. This thread has convinced me to, first,
unsubscribe from this list immediately, because the information isn't
worth exposure to this kind of toxicity, and second, start moving away
from Arch, because I can't trust it to ship good code.

The immediate response and a good bit of the followup was acutely
hostile to both the reporting user and to the ability of this
community to build good software. It argues to me that I cannot trust
Arch to comprehend a world outside its little bubble, think about its
users, acknowledge possible bugs that aren't instantly obvious to the
Arch staff, cause issues to be upstreamed, or maintain a climate of
discussion that is conducive to discussing problems and fixing
them. Evaporative cooling of group beliefs ensures that
honesty-brutality culture inevitably spirals into a festering
close-minded pit that cannot accept outside contributions or think of
the bigger picture. Maintaining the free flow of information is
important, but it must be done in the context of the larger community
- a tiny walled-off group can communicate as freely as it wants inside
itself, but if nothing goes over the wall there might as well be no
free flow at all.

Even if the original report was not flawless, even if it was a repeat,
even if it was sent to the right people, hostile repression was not
the correct response. If nothing else, the fact that it's a repeat
should be demonstrated and more deeply evaluated. This time it ended
up working out, but if this is representative of the Arch community I
can't trust it to handle other bugs. How many more severe issues are
hiding in Arch, or in upstream packages, because the original reporter
was already having a bad day and just gave up? Because people aren't
emotionless robots and a horrible thread like this stressed someone
out enough to cause an error? Because someone jumped to an incorrect
conclusion and shut down discussion prematurely?

Answer: Too many for my liking.

--

Saul Reynolds-Haertle
Jonathon Fernyhough
2017-12-09 22:16:16 UTC
Permalink
a lot :)
Come over to Manjaro. :)

J
Jonathon Fernyhough
2017-12-09 22:17:13 UTC
Permalink
Well, that was a good use of "reply"...

Apologies.
Morten Linderud via arch-general
2017-12-09 23:51:09 UTC
Permalink
Post by Jonathon Fernyhough
a lot :)
Come over to Manjaro. :)
J
I think we both know very well that the state of security in Manjaro is way
worse then Arch.
--
Morten Linderud

PGP: 9C02FF419FECBE16
Jonathon Fernyhough
2017-12-10 00:10:26 UTC
Permalink
On 09/12/17 23:51, Morten Linderud via arch-general wrote:> I think we
both know very well that the state of security in Manjaro is way
Post by Morten Linderud via arch-general
worse then Arch.
Ah, that old chestnut again. :)

At the risk of going entirely off-topic, you might also note the
difference in how your input on the Manjaro forums was received compared
to similar on the Arch forums.

J
Ralf Mardorf
2017-12-09 22:20:47 UTC
Permalink
On Sat, 9 Dec 2017 17:04:33 -0500, Saul Reynolds-Haertle via
arch-general wrote: [snip]

You missed the point, it was discussed three years ago. It's done.
Note, I'm not using procps-ng from core.
Mar77i via arch-general
2017-12-10 00:33:57 UTC
Permalink
Subject: Re: [arch-general] Proposal: add "--disable-modern-top" to procps-ng configure flags
This is an absolutely horrible response and let me tell you: telling others what
to do is not how you should live, think, use computers or (FOSS) software.
So first of all, I hope you use computers because they make getting your job
done easy enough _to you_. Anything beyond can in fact be viewed as you acting
irresponsibly.
Apologies if this is misformatted, and I hope it works; I didn't
expect to be responding and am working in the system optimized for
readability over composition.
What does your first paragraph even mean? You hope we see your reply in a way
that pleases us, which might be on braille readers or piped to espeak to be
played on commute. You carry a hint of how others are supposed to receive your
content, and you state this first, maybe because you think that's more important
than what you're actually saying. Then you say something about how you have to
be "working in the system", which I'll just interpret as you running your mail
program as root. *shrug*. That system is then optimized for readability over
composition. Both terms so overused since the invention of the personal computer
that I don't even remember what they mean any more.
I subscribed to this list just last night in hopes of gaining better
visibility into the tools that I use. I have, and I think that I
The twist in "gaining better visibility into the tools that I use" is nothing
short of brilliant. I hardly understand the sentence, right between "you'd like
to gain better visibility", as in you want to be seen and
"visibility into the tools", which might mean that you imagine you're swimming
in more bright blue waters somewhere closer to where the software you're using
comes from.

Thing is that this isn't some zelda role-playing game. You're talking to actual
people with actual responsibilities and actually share their time with their
work, their families and whomever else they decide to spend their lives with.
should report my findings. This thread has convinced me to, first,
unsubscribe from this list immediately, because the information isn't
worth exposure to this kind of toxicity, and second, start moving away
from Arch, because I can't trust it to ship good code.
So one thing that hasn't existed 10 years ago is framing fiction as facts like
you are doing it here. You're basically imagining that you have to stay away
from discussions where somebody tells you you're wrong, and completely
caricature any act of verbal violence against you by completely ignoring whether
they might have had a point. Either you're caught in a case of backfire effect
or you were told how terribly things were going around here only looking for
some confirmation - See also: confirmation bias.
The immediate response and a good bit of the followup was acutely
hostile to both the reporting user and to the ability of this
community to build good software. It argues to me that I cannot trust
Community? Build? Good? Software? Dude, most of us got the package in question
on their hard drive from a pacman -S under some sort of brain-outage or
automatically by whatever installation script they had at the time they
installed it. That said, yes, some hostility might occur.
I'll get to what you should do with it in a minute.
Arch to comprehend a world outside its little bubble, think about its
users, acknowledge possible bugs that aren't instantly obvious to the
Arch staff, cause issues to be upstreamed, or maintain a climate of
discussion that is conducive to discussing problems and fixing
them. Evaporative cooling of group beliefs ensures that
honesty-brutality culture inevitably spirals into a festering
close-minded pit that cannot accept outside contributions or think of
the bigger picture. Maintaining the free flow of information is
important, but it must be done in the context of the larger community
a tiny walled-off group can communicate as freely as it wants inside
itself, but if nothing goes over the wall there might as well be no
free flow at all.
You know you're slandering. What you're saying is because you did not get your
say, nobody gets their say even if they might be right, and the people who
create the content (PKGBUILDs for our packages) have all the time they need to
grant every unimportant user's wish. Last time I checked, nope, that's not the
case. Double-checking, because you seem desperate, nope, still not the case.
Even if the original report was not flawless, even if it was a repeat,
even if it was sent to the right people, hostile repression was not
the correct response. If nothing else, the fact that it's a repeat
should be demonstrated and more deeply evaluated. This time it ended
up working out, but if this is representative of the Arch community I
can't trust it to handle other bugs. How many more severe issues are
hiding in Arch, or in upstream packages, because the original reporter
was already having a bad day and just gave up? Because people aren't
emotionless robots and a horrible thread like this stressed someone
out enough to cause an error? Because someone jumped to an incorrect
conclusion and shut down discussion prematurely?
You overgeneralized ("if this is representative"), you talked about bugs like
OP should be treated the same as anyone who can't boot their system after
yesterday's updates. Even then, the very best that arch's staff should be doing
is to try make you come up with configuration, environment information and
whatever else debug data, and tell you where to create a bug report.
But in above paragraph, you make it look like people's emotions are more
important than technical accuracy, framed in a way which is seriously worhty of
FOX news.

As promised, I'm going to tell you what to do if you feel like you're getting
shut down: get some data, create your own bubble and use that AUR package, don't
give up on a bunch of people who are so tired of discussing taste and cosmetic
adjustments. That's not what they enjoy to spend their weekends on.

cheers!
mar77i

Sent with [ProtonMail](https://protonmail.com) Secure Em
Bartłomiej Piotrowski via arch-general
2017-12-10 12:25:01 UTC
Permalink
Given how derailed this thread became, I'm enabling moderation for all
new messages on arch-general from now on.

Bartłomiej

Loading...