[arch-general] procps-ng 3.3.13 and its new topdefaultrc
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/55a42ae040eaa19fd3089f56d98ccbde5... [2] https://github.com/manjaro/packages-core/blob/master/procps-ng/topdefaultrc
On 04/10/2018 07:05 PM, Jonathon Fernyhough wrote:
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/55a42ae040eaa19fd3089f56d98ccbde5... [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... -- David C. Rankin, J.D.,P.E.
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.
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). On 04/11/2018 12:53 PM, David C. Rankin wrote:
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...) -- Eli Schwartz Bug Wrangler and Trusted User
On 04/11/2018 12:08 PM, Eli Schwartz via arch-general wrote:
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? -- David C. Rankin, J.D.,P.E.
On Wed, Apr 11, 2018 at 03:20:10PM -0500, David C. Rankin wrote:
On 04/11/2018 12:08 PM, Eli Schwartz via arch-general wrote:
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, -- Leonid Isaev
On 04/11/2018 04:36 PM, Leonid Isaev via arch-general wrote:
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
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.
On 4/11/18, Eli Schwartz via arch-general
On 04/11/2018 04:36 PM, Leonid Isaev via arch-general wrote:
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
On 04/11/2018 04:20 PM, David C. Rankin wrote:
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.
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.
It defines ORIG_TOPDEFS which gets used in places like https://gitlab.com/procps-ng/procps/blob/55a42ae040eaa19fd3089f56d98ccbde5a9...
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. :) -- Eli Schwartz Bug Wrangler and Trusted User
participants (5)
-
Carsten Mattner
-
David C. Rankin
-
Eli Schwartz
-
Jonathon Fernyhough
-
Leonid Isaev