[arch-general] procps-ng 3.3.13 and its new topdefaultrc

[Jonathon Fernyhough]

Much as I'm wary about raising this after last time... here goes. Really
just putting this out there as a thing to consider if it's not already
known about.

With 3.3.13, upstream introduced support for a system-wide default
toprc, /etc/topdefaultrc [1]. This is their "recommended" way of setting
sensible/usable/accessible defaults rather than the "all or nothing"
--disable-modern-top.

I don't know what the specific implementation differences are between
the two (e.g. whether topdefaultrc is compatible with/overrides
--disable-modern-top) but it should provide an approach more "aligned to
upstream". Coming up with a "sensible default", on the other hand, is
likely to be more complicated...

(I've gone for an htop-like scheme with a nice green 'column heads',
idle tasks off (i), Zero-Suppress on (0), for Manjaro [2].)

[1]
https://gitlab.com/procps-ng/procps/commit/55a42ae040eaa19fd3089f56d98ccbde5a9abc3a
[2]
https://github.com/manjaro/packages-core/blob/master/procps-ng/topdefaultrc

[David C. Rankin]

Post by Jonathon Fernyhough
Much as I'm wary about raising this after last time... here goes. Really
just putting this out there as a thing to consider if it's not already
known about.
With 3.3.13, upstream introduced support for a system-wide default
toprc, /etc/topdefaultrc [1]. This is their "recommended" way of setting
sensible/usable/accessible defaults rather than the "all or nothing"
--disable-modern-top.
I don't know what the specific implementation differences are between
the two (e.g. whether topdefaultrc is compatible with/overrides
--disable-modern-top) but it should provide an approach more "aligned to
upstream". Coming up with a "sensible default", on the other hand, is
likely to be more complicated...
(I've gone for an htop-like scheme with a nice green 'column heads',
idle tasks off (i), Zero-Suppress on (0), for Manjaro [2].)
[1]
https://gitlab.com/procps-ng/procps/commit/55a42ae040eaa19fd3089f56d98ccbde5a9abc3a
[2]
https://github.com/manjaro/packages-core/blob/master/procps-ng/topdefaultrc

I have boxes from 2 - 16 cores. In the past, you get old top on anything
4-cores or less. You get modern-top on anything with more than 4-cores --
that's just nuts. At first I didn't care for the new top, now I'm quite happy
with it, and in fact prefer it. Nothing more frustrating that what top you get
being "like a box of chocolates". Two xterms open, one to an 8-core box shows
new-top, one to a dual-core box show old-top -- that's nuts.

The PKGBUILD change for rebuilds is simple, but we ought to have one or the
other (modern preferred here, but I have nothing against someone else wanting
the old top view available) If a simple config can make both happy - that
seems like a no brainer. Otherwise, I'll keep using asp to grab the latest and
fix it myself by removing the --disable-modern-top build option.

# --disable-modern-top \

Consistency beats a 'box-of-chocolates' any day...

[Carsten Mattner via arch-general]

I haven't seen the modern top ui, but it sounds useful and I'd
be in favor of it if it doesn't break things.

But I have to note that terminal emulators and coloring curses
applications is very hard to do in a way that works across
everyone's favorite color scheme. It's bound to result in
invisible elements or missing contrast when you use too much
coloring. It's not a fault of the designer but the ways terminal
emulators work (in other words are limited).

So by all means, if it doesn't break anything, enable modern
top, but use caution with colors.

[Eli Schwartz via arch-general]

If I actually used top after discovering htop, I would prefer the old
look (which our new procps-ng maintainer has apparently made an
executive decision to use).

Post by David C. Rankin
The PKGBUILD change for rebuilds is simple, but we ought to have one or the
other (modern preferred here, but I have nothing against someone else wanting
the old top view available) If a simple config can make both happy - that
seems like a no brainer. Otherwise, I'll keep using asp to grab the latest and
fix it myself by removing the --disable-modern-top build option.
# --disable-modern-top \
Consistency beats a 'box-of-chocolates' any day...

Why would you rebuild it, though, just to modify the *default*
configuration? Why not create your own /etc/topdefaultrc?

It's ironic, I guess, that the procps-ng developers did this in order to
provoke people into learning how to configure top, but now we have
people preferring the old look, who complain when the default changes,
and then when we revert to the old look we have people complaining about
the old look, but no one seems interested in, well, configuring it as
upstream intended...

(Kudos to Jonathon for being principled enough in both desiring
distro-customized defaults for Manjaro users and implementing them the
right way. I wonder if anyone will actually learn how to use top though...)

[David C. Rankin]

Post by Eli Schwartz via arch-general
It's ironic, I guess, that the procps-ng developers did this in order to
provoke people into learning how to configure top, but now we have
people preferring the old look, who complain when the default changes,
and then when we revert to the old look we have people complaining about
the old look, but no one seems interested in, well, configuring it as
upstream intended...
(Kudos to Jonathon for being principled enough in both desiring
distro-customized defaults for Manjaro users and implementing them the
right way. I wonder if anyone will actually learn how to use top though...)

It's ironic the configuration allowing the choice between the new/old
interfaces isn't described clearly, or at all, in 'man top'. The Alternate
Display 'A', has nothing whatsoever to do with whether modern top is display.
From my read of the man page, neither an option concerning the modern top
display, or its build flag are discussed at all.

In fact, the only reference to the build flag is on line 8633 of the configure.ac:

AC_ARG_ENABLE([modern-top],
AS_HELP_STRING([--disable-modern-top], [disable new startup defaults, return
to original top]),
[], [enable_modern_top=yes]
)

The only changes (in source code - NEWS file) relevant to modern-top and
config file, is that as of 3.3.5 modern-top will honor the old config file
without having to --disable-modern-top, but this has nothing to do with the
interface and there is no discussion whatsoever about configuring between the
two interfaces.

Did I miss something obvious? Are you suggesting there is a simply toprc flag
that allows choosing between old and new top interfaces?

[Leonid Isaev via arch-general]

Post by David C. Rankin

Post by Eli Schwartz via arch-general
It's ironic, I guess, that the procps-ng developers did this in order to
provoke people into learning how to configure top, but now we have
people preferring the old look, who complain when the default changes,
and then when we revert to the old look we have people complaining about
the old look, but no one seems interested in, well, configuring it as
upstream intended...
(Kudos to Jonathon for being principled enough in both desiring
distro-customized defaults for Manjaro users and implementing them the
right way. I wonder if anyone will actually learn how to use top though...)

Did I miss something obvious? Are you suggesting there is a simply toprc flag
that allows choosing between old and new top interfaces?

It should also be mentioned that ~/.toprc is the most hideous config file on my
system :) And FWIW, I don't think that upstream wanted to provoke any learning
-- they just made a change for the sake of it (probably following GNOME 3.x :).

Cheers,

[Eli Schwartz via arch-general]

Post by Leonid Isaev via arch-general
It should also be mentioned that ~/.toprc is the most hideous config file on my
system :) And FWIW, I don't think that upstream wanted to provoke any learning
-- they just made a change for the sake of it (probably following GNOME 3.x :).

I don't disagree on either count, but I'm pretty sure they *claimed*
that reason.

[Carsten Mattner via arch-general]

FWIW and thankfully, we're not all wired the same, and I can
say with certainty that I find htop irritating and confusing,
having used FreeBSD and procps top for decades. There is
a learning curve, I guess, or we're using/missing different
features.

But to return to the important point, does anyone have a
screenshot of modern-top?

And, like David, I'm wondering if I can toggle modern-top
before coming up with full toprc theme.

Post by Eli Schwartz via arch-general

Post by Leonid Isaev via arch-general
It should also be mentioned that ~/.toprc is the most hideous config file on my
system :) And FWIW, I don't think that upstream wanted to provoke any learning
-- they just made a change for the sake of it (probably following GNOME 3.x :).

I don't disagree on either count, but I'm pretty sure they *claimed*
that reason.
--
Eli Schwartz
Bug Wrangler and Trusted User

[Eli Schwartz via arch-general]

Post by David C. Rankin
It's ironic the configuration allowing the choice between the new/old
interfaces isn't described clearly, or at all, in 'man top'. The Alternate
Display 'A', has nothing whatsoever to do with whether modern top is display.
From my read of the man page, neither an option concerning the modern top
display, or its build flag are discussed at all.

Since I don't use top, I wouldn't know... if the modern-top definition
is not described there, you could, I dunno, *reproduce* it? By learning
how it works.

Post by David C. Rankin
AC_ARG_ENABLE([modern-top],
AS_HELP_STRING([--disable-modern-top], [disable new startup defaults, return
to original top]),
[], [enable_modern_top=yes]
)
The only changes (in source code - NEWS file) relevant to modern-top and
config file, is that as of 3.3.5 modern-top will honor the old config file
without having to --disable-modern-top, but this has nothing to do with the
interface and there is no discussion whatsoever about configuring between the
two interfaces.

It defines ORIG_TOPDEFS which gets used in places like
https://gitlab.com/procps-ng/procps/blob/55a42ae040eaa19fd3089f56d98ccbde5a9abc3a/top/top.h#L251

Post by David C. Rankin
Did I miss something obvious? Are you suggesting there is a simply toprc flag
that allows choosing between old and new top interfaces?

I didn't suggest that, I suggested the new top interface could almost
certainly be reimplemented if you know the right top options... probably
by like reading documentation.

I consider top to be an exercise in frustration, so won't try myself,
but analyzing top.h as I referenced would probably let you do this. :)