You are not logged in. Please login or register.
We are very pleased and happy to announce the newest release of Hyperbola GNU/Linux-libre with v0.4.4.
See our official news for further details.
HyperForum → Packages → energy management
Good evening. Please tell me what Hyperbola tool is used to manage energy consumption, for a notebook.
If there is, please write the name of the package.
Thank you.
Good evening. Please tell me what Hyperbola tool is used to manage energy consumption, for a notebook.
If there is, please write the name of the package.
Thank you.
This will work for now, while its GNU/Linux-Libre but after HyperbolaBSD is out, it likely won't work anymore unless fixes are made.
upload.disroot.org/r/k4C29osW#WTJcIiXOlcwPD78SeezoIJiz0BOmnt+ssumcNCVMIgw=
If you prefer though, I could just give you a PKGBUILD I have. Although, I would need to change the key signatures.
Link scrambled
Please do not offer pre-compiled binaries and instead the sources for compilation. Thanks!
https://git.hyperbola.info:50100/~team/ … c00773679c
thank you!
But I meant something else.
I need a way to change the power profile and manage energy conservation without the need to write the code.
And that should be easy.
Those are strict bound on the kernel itself and as we have no interest to support GNU/Linux-libre that deep we do not offer such. If you know a different way from BSD or can give some examples for your intended way?
And in Hyperbola, BSD, it's real?
If I find an option for linux, I'll write it for myself.
Okay, that is exactly not working with Hyperbola as that is part of power-profiles-daemon and needs:
D-Bus
upower
polkit
HyperbolaBSD itself is also not supporting bloated implementations alike those named.
Yes, I was wrong. Az completely relinquished the use of dbus. cpupower does not require dbus.
On cpupower there comes the second problem: Completely bound into the Linux-kernel itself. So we are not able to have an independent implementation with this project. Integration would bind time and energy maintaining it. As said: If there is the wish to have it, no issue. But that needs a community-port made and not a package within the repositories of Hyperbola itself.
I hope you find a way or create your prophecy in hyperbola BSD, because many use hyperbola through laptops and need to save battery charges at times, and that everything works well.
Thank you!
Here's another option: cpufrequtils, what can you say about him?
No one has a minus, does he have a connection to the core?
As said: Hyperbola is following a simple approach ... the base system with further packages being needed for sure is provided. The rest is up to the community to provide a package. Read here about the philosophy behind: https://wiki.hyperbola.info/doku.php?id … ble_system
To quote:
If you miss something, try it yourself building, make proposals and share your insights.
There is also a thread regarding packages: https://forums.hyperbola.info/viewtopic.php?id=773
If you like to provide a port / package for cpupower working on Hyperbola GNU/Linux-libre, feel free to provide one and feel always invited to do so. You can create also here in this category a new thread for your own made package and port as cpupower is meant as running service and therefore needs for sure definitions for openrc and runit.
But to say it clear: I have for the moment no time to provide any new package as I'm busy with 0.4.5 for Hyperbola GNU/Linux-libre. We are following there our roadmap: https://wiki.hyperbola.info/doku.php?id … y_way_v045
Link scrambled
Please do not offer pre-compiled binaries and instead the sources for compilation. Thanks!
You should however then change to version 2.0.
That is the newest version of auto-cpufreq that can be used. Each one after, doesn't work without big changes.
IE, I don't know how to make 2.1 or newer work. 
Here is a link the way you want it to be though.
EDIT: Needs fixing.
Yes, it needs fixing. zapper and me talked about this yesterday in IRC. The point here is besides the clear point that energy-management is inbound to the system and its kernel: Many projects are clearly out of bounds. What does this mean? The project auto-cpufreq was removed out of reasoning.
It got clear yesterday why many Python-projects are going to be a catastrophe on the long run: We cannot rely on them as we never know if the same dependency-tree is also working for the next released stable version. In regards to auto-cpufreq: This is not working and the dependency-tree changed drastically more to even no longer really focussed to be offline possible compiled as stable tarball. Upstream git was now included and demanded for further compilation. Also pip and we have a clear reasoning why we reject package-management within packages. We have one package-manager, we do not need another one or even worse like in that case pip sideloading data from pypi at build-time.
That's the reasoning why we remove also Python-packages when upstream-maintainers are doing such ways. It is their right to do, no doubt. But from security-point this is and stays a catastrophe. Who knows exactly the full list of dependencies in the sideload? And how to verify them being trustworthy in that concrete version downloaded? The xz-issue showed exactly the point. And why do many maintainers ignore this in the Python-sphere? We end up at a point where every new release is going to be a hard and long way of inclusion. This cannot be the goal because long-term and stable focused systems suffer under such circumstances.
Thread closed!
HyperForum → Packages → energy management
Powered by PunBB, supported by Informer Technologies, Inc.