Here is what I see on my system (UbuntuMATE 22.04.4 LTS):
root:~# man -k cpupower
cpupower (1) - Shows and sets processor power related values
cpupower-frequency-info (1) - Utility to retrieve cpufreq kernel information
cpupower-frequency-set (1) - A small tool which allows to modify cpufreq settings.
cpupower-gui (1) - Set the scaling frequencies and governor of a CPU
cpupower-idle-info (1) - Utility to retrieve cpu idle kernel information
cpupower-idle-set (1) - Utility to set cpu idle state specific kernel options
cpupower-info (1) - Shows processor power related kernel or hardware configurations
cpupower-monitor (1) - Report processor frequency and idle statistics
cpupower-set (1) - Set processor power related kernel or hardware configurations
root:~# which cpupower
/usr/bin/cpupower
root:~# which cpupower-frequency-info
root:~# which cpupower-frequency-set
root:~# which cpupower-gui
/usr/bin/cpupower-gui
root:~# which cpupower-idle-info
root:~# which cpupower-idle-set
root:~# which cpupower-info
root:~# which cpupower-monitor
root:~# which cpupower-set
root:~#
The man page for "cpupower" states:
SEE ALSO
cpupower-set(1), cpupower-info(1), cpupower-idle-info(1), cpupower-idle-set(1), cpupower-frequency-set(1), cpupower-
frequency-info(1), cpupower-monitor(1), powertop(1)
I suggest you scan the full page, as the -k option means you're searching for specific detail & not reading the key context around it that explain what you're seeing.
What you're reading is detail related to other pages and not commands, but explanation pages that detail specific options related to a feature, eg. your refer to cpupower-freqency-info as if its a command, however if you'd used man cpupower-frequency-info you'd note its referring to specific ways of using the cpupower command.
If unsure; try reading the full page to get the context of what your usage of -k is showing.
Thank you for that clarification, but I have a few years of experience under my belt. Also, the script clearly shows, as you state, that all action is performed by various incarnations of the "cpupower" command itself.
When I see language like "Utility to ...", as is used for
cpupower-frequency-info (1) - Utility to retrieve cpufreq kernel information
cpupower-idle-info (1) - Utility to retrieve cpu idle kernel information
it is expected that the reference is to an executable "command", especially when we are talking of group 1 man pages, which is the case here. Otherwise, I would expect such pages to be re-assigned to the group 8 man pages, intended for maintenance and informational.
If not a specific command reference, I would expect the language to be something like "Guidance on 'cpupower' mode ...", which should definitely bump such man pages to man group 8.
In [almost all] most cases; the man pages along with source code come from upstream packages.
If you believe it's a problem, or needs correction, I'll suggest the best place is filing a bug with upstream. The pages/tools come from Ubuntu – Details of package linux-tools-common in jammy which only mentions Ubuntu specific teams, but I note the same text also on OpenSuSE & Debian when I checked, so I do believe you'll need to have it changed with report upstream.
I understand the "concept" of upstream, have no qualms about it, and abide by it.
However, from the moment that the distro (in this case UbuntuMATE) deploys a "standard" configuration which offers, as a "programmed" option, as one of the listed choices, to select the "CPU Scaling Frequency Monitor" as a applet for addition to the panel, then I take that stance (rightly or wrongly) for the distro having taken partial ownership of the applet, with that encompassing the "responsibilities" associated with such ownership.
Having that listed as part of that menu projects a far different stance towards that package than does seeing a package listed, for example, among others in the offerings presented within Synaptic "supermarket".
While I will "bend" to comply with what is being communicated as the thing to do, I do so under protest, given my user-oriented perspective stated above.
the results of such a survey, for every reported issue, this would go a long way to
put visibility on the scope of impact from each issue, or
put visibility on the lack of shared perception of importance/criticality of the issue to the community.
It is my strong belief that having such a visible "pulse" on all such issues would make UM a very attractive Community to join.
@mdd12, regarding your specific reference to LibreOffice, a case could be made for that stance ... but I know when not to push my luck ... on the basis that LibreOffice is too massive a package, edging towards the size of the OS itself ... and that would be an unreasonable expectation, likewise for web browsers and mail clients !
However, if the UM developers noticed a trend of issues that were specifically being reported ONLY (or predominantly) by members of the UM Community, then I would be persuaded to rationalize that UM developers should be able to recognize their own interests (functionality and desirability of the UM Distro) are being undermined by not taking a more active part, along the lines I outlined at the beginning of this response.
First a disclaimer: I'm a user just like you. I'm not a developer or ubuntu-mate team member
Since you are a part of the support forum now and considered a highly experienced volunteer and not joe-average-user, this will not fly.
If it is really a burden to you, you could just file a bug on launchpad like every other user is supposed to do (or ask someone to do it for you) and call it a day.
I searched for the info for you and showed you a shortcut, you are not obliged to follow suit, but this way it might be of more help to the total community, not just Ubuntu.
Remember: UNIX is like a church, Linux is like a bazaar.
Linux can only exist because we all give a little bit of ourselves, it is a community effort.
More musings about the philosophy of Linux vs Commercial entities:
Linux is NOT Windows , differences between Commercial and community driven software models (take especially note of #3a).
Used Example here is Windows but you can also replace that with HP-UX / Solaris / VMS / Xenix or any other commercial entity.
Regarding the two document references provided, I have seen those before on a few occasions. Every time I revisit Mr. Raymond's "cry from the heart", I see new nuances that I did not perceive on previous passes.
I am fully cognizant that the UbuntuMATE development Team is NOT a corporate entity.
However, they have already formed their Community of like-minded volunteers ... who have gravitated towards a shared vision/goal (our well-loved UbuntuMATE) and work in a concerted fashion for such. Case in point:
They created this forum for Community members to connect and share observations, experiences and ideas, providing the mechanism for initial introductions that could lead to joint efforts on a shared focus.
They already monitor the "pulse" of the Community in their own fashion (each their own focus and frequency).
They already communicate with one-another and discuss concepts, methods, come to consensus ... then pursue and deploy implementations.
They also review, discuss and implement methodologies ... to make their shared objective an easier goal ... to achieve and maintain on an ongoing basis.
For those reasons, in my view, there is no conflict between what I have expressed as an approach ... and what they need to do from their own perspective ... "in order to tame the wild beast" and keep all those ducks in a row!
As we all know, automation (however low-tech the implementation) is a wonderful thing!
Lastly, regarding the references to the package source for cpu_power, I do thank you for that. I will always pursue matters at source, which is where it needs to be dealt with, as you indicated, until the happy day when things have evolved into what I perceive as a better approach to build a stronger UbuntuMATE Community. The fact that I did not address this point in my earlier replies should not have been interpreted as indicating a lack to pursue matters via the "proper" channel(s).
---- edit ----
I've contacted [email protected] directly, because the OpenSUSE link didn't take me anywhere that I could enter a request for review/action.
