Linux tlp.conf: Den profilbezogenen Charakter der Parameter deutlicher machen?

[linrunner]

Moin,

ihr erinnert euch, mit TLP 1.9.0 wurde ein zusätzlicher Betriebsmodus namens power-saver (für maximale Energieeinsparungen) eingeführt. Die zuvor vorhandenen Modi für Netz- und Akkubetrieb wurden in performance und balanced umbenannt. Von da an wurden die Modi als „Profile“ bezeichnet.

Um dies in der tlp.conf abzubilden, wurden Parameter mit dem neuen Suffix _ON_SAV eingeführt. Die bestehenden Suffixe für die alten Modi, _ON_AC und _ON_BAT, blieben unverändert und wurden direkt den Profilen performance und balanced zugeordnet.

Das Ergebnis zeigt das folgende Beispiel:

CPU_ENERGY_PERF_POLICY_ON_AC # Dem performance-Profil zugeordnet
CPU_ENERGY_PERF_POLICY_ON_BAT # Dem balanced-Profil zugeordnet
CPU_ENERGY_PERF_POLICY_ON_SAV # Dem power-saver-Profil zugeordnet

Diesen Ansatz habe ich damals bewusst gewählt, um die Rückwärtskompatibilität mit der großen Anzahl bestehender benutzerdefinierter Konfigurationen zu gewährleisten.

Mit TLP 1.10.0 trat eine weitere Komplikation hinzu, die die Konfiguration schwerer verständlich machte. Als Reaktion auf Feature-Anfragen wurde die feste Zuordnung Netzstrom == performance und Akkustrom == balanced aufgehoben und stattdessen über TLP_PROFILE_AC und TLP_PROFILE_BAT konfigurierbar gemacht.

Kürzlich erhielt ich Rückmeldungen, dass diese Situation verwirrend ist, da die Nutzer die Suffixe _ON_AC und _ON_BAT nach wie vor eher mit den Stromquellen selbst als mit den zugewiesenen Profilen in Verbindung bringen.

Vorschlag

Es wurde folgende Alternative vorgeschlagen, die die Zuordnung zu den Profilen eindeutig kennzeichnet:

CPU_ENERGY_PERF_POLICY_ON_PRF # Dem performance-Profil zugeordnet
CPU_ENERGY_PERF_POLICY_ON_BAL # Dem balanced-Profil zugeordnet
CPU_ENERGY_PERF_POLICY_ON_SAV # Dem power-saver-Profil zugeordnet

Da die Rückwärtskompatibilität zu bestehenden Konfigurationen nicht aufgegeben werden darf, müsste TLP die alten Parameternamen zur Laufzeit den neuen zuordnen. Mit anderen Worten: eure Konfigurationsdateien bleiben unverändert; TLP konvertiert die Parameter bei jeder Ausführung. Ich halte dies für machbar. Andererseits kann ich mir keine zuverlässige, automatisierte Methode vorstellen, um die Konfigurationsdateien umzuschreiben.

Da ältere Versionen von TLP aufgrund der Release-Zyklen der Distributionen über längere Zeiträume hinweg im Einsatz bleiben, müsste die Doku-Website für alle Parameter die alten Namen neben den neuen auflisten. Das würde die Dokumentation schwerer lesbar machen.

Fragen an euch:

1. Überwiegen aus eurer Sicht die Vorteile der neuen Lösung die Nachteile?
2. Welche Vor- und Nachteile seht ihr bei der neuen Lösung für eure konkreten Anwendungsfälle?
3. Habt ihr noch weitere Anmerkungen?

Ich freue mich auf eure Meinungen. Vielen Dank im Voraus!

Auf GitHub gibts da Ganze ebenfalls: https://github.com/linrunner/TLP/issues/899

 

[mcb]

Schwierige Frage.
1. Es wäre dann verständlicher
2. Es ist ansich ok so wie es ist. Vielleicht könnte man die Dokumentation noch dahin verdeutlichen,das AC & BAT die Standartprofile sind (und bleiben).
3. Muß ich erstmal in Ruhe bebrüten

Weiß nicht so recht ob sich der ganze Aufwand lohnt.

 

[xxxx]

1. Überwiegen aus eurer Sicht die Vorteile der neuen Lösung die Nachteile?

Auf jeden Fall. Ich bin allerdings kein Durchschnittsnutzer, und mache unter Linux vieles viel lieber mit der Kommandozeile als mit einem GUI. Und ich lese Dokumentationen

2. Welche Vor- und Nachteile seht ihr bei der neuen Lösung für eure konkreten Anwendungsfälle?

Insofern ich das als Vorteil betrachte: Ganz klar die Konfigurierbarkeit.

3. Habt ihr noch weitere Anmerkungen?

Abwärtskompatibilität ist wichtig, darf aber kein Ewigkeits-Feature sein. Überschaubarkeit der Komplexität hat in meinen Augen einen ähnlich hohen Stellenwert (das bedarf aber stets einer kontextbasierten Abwägung).

 

[thickpad]

Hi @linrunner ich finde es cool das du diesen Schritt nach vorne in Erwägung ziehst oder nach Möglichkeiten suchst.

Hab das neulich schon prophezeit wo du dann noch mehr auf Abwärtskompatibilität warst als ich mein Config-Snippet völlig falsch gebaut hatte aufgrund dieser miss-Deutlichkeit beim Versions-Sprung.

Es führt für mich nix an den neuen Suffixen vorbei so kann man die Profile unabhängig von AC / BAT Aktiv schalten.

Persönlich würd ich das auch mit nem harten Schnitt machen, bzw., bei der Installation Ankündigen das die Config zu überarbeiten ist. Evtl. könnte man es mit einem Link machen was wie prägnant zu tun ist und halt nicht mehr diese Altlasten mitziehen oder Parameternamen zur Laufzeit neu zu ordnen. Mein Gott das sind Linux-Leute dann müssen sie ihre Config halt mal überarbeiten bei einer Neuinstallation. Tun die meisten ja eh ständig und oft.

Warnen ja, Lauftzeitskonversion nein. Abwärtskompatiblität kann auch sein das manche Parameter in der neuen Version einfach ignoriert werden bis man es überarbeitet . Startet ja dann noch das Programm = Abwärtskompatibel.

 

[linrunner]

Weiß nicht so recht ob sich der ganze Aufwand lohnt.

Das frage ich mich ja auch.

 

[mcb]

Das frage ich mich ja auch.

Momentan denke ich eher nicht?
Der ganze Aufwand damit aus

CPU_ENERGY_PERF_POLICY_ON_AC
CPU_ENERGY_PERF_POLICY_ON_BAT

dann

CPU_ENERGY_PERF_POLICY_ON_PRF
CPU_ENERGY_PERF_POLICY_ON_BAL

wird.
Und dann betrifft es nur die User die die Standartprofile verändern. Denen ist dann auch zuzutrauen das sie das (meist) überblicken.
Ich habe tlp auf autoswitch 1 mit AC/Bat. Für Sonderwünsche des Users mcb einen alias s -> power-saver und b -> ballanced. Das reicht mir.

 

[linrunner]

Der technische Aufwand, die Parameter zur Laufzeit dynamisch umzubenennen, ist gar nicht so hoch. Den Mechanismus hab ich schon vor längerer Zeit (1.4.0) eingebaut, aber nie intensiv genutzt. Sind im Grund nur Einträge in eine Datei: https://github.com/linrunner/TLP/blob/main/rename.conf

Man könnte da auch leicht noch einen Hinweistext für tlp-stat [-c | --cdiff] ergänzen. Das mache ich heute schon Features, die entfernt werden (ja, das gibt's, aber nur für wenig genutztes): https://github.com/linrunner/TLP/blob/main/deprecated.conf

Ich mache mir eher Sorgen um

1. Die Verständlichkeit der Dokumentation, die plötzlich um sehr viele Fallunterscheidungen wächst
2. Wie die dynamische Umbenennung von der Usern wahrgenommen wird: tlp-stat [-c | --cdiff] würde für alte Konfigurationen die neuen Parameter-Namen anzeigen - das könnte mehr verwirren als die alten Suffixe

Und dann betrifft es nur die User die die Standartprofile verändern. Denen ist dann auch zuzutrauen das sie das (meist) überblicken.

Das dürfte schon oft zutreffen. Aber wie bekommen sie es beim Paketupgrade mit? Es lesen ja auch nicht alle die Release Notes, schon gar nicht jedesmal.

bei der Installation Ankündigen das die Config zu überarbeiten ist.

Nicht jeder User macht das auf der Kommandozeile, oft kommen GUIs zum Einsatz - klick und weg...

Es bietet auch nicht jede Distri die Möglichkeit hier etwas anzuzeigen und vor allem müsste das jeder Maintainer distri-individuell ins Paket einbauen. Das wäre richtig Aufwand...

Mein Gott das sind Linux-Leute dann müssen sie ihre Config halt mal überarbeiten bei einer Neuinstallation.

Es geht mir nicht um Neuinstallation sondern um turnusmäßige Paket-Upgrades.

 

[mcb]

Sind im Grund nur Einträge in eine Datei: https://github.com/linrunner/TLP/blob/main/rename.conf

Dadurch würden ja die alten Configs weiter funktionieren.

Beitrag automatisch zusammengeführt: 21 Juli 2026

Edit:

changelog: extend radio switching · linrunner/TLP@8695be2

TLP - Optimize Linux Laptop Battery Life. Contribute to linrunner/TLP development by creating an account on GitHub.

github.com

Oh auch sehr schön (Sorry für offtopic)

 

[Ambrosius]

Ich kann die Verwirrung um AC und BAT und die intuitive Zuordnung zu den Stromquellen sehr gut nachvollziehen, nicht zuletzt bin ich dem auch auf den Leim gegangen. Der Grund hierfür ist einfach die weite Verbreitung davon und dass es sich de facto als Standardbezeichnung durchgesetzt hat.
Ich seh hier Vor und Nachteile genau wie jeder andere auch, aber ich versucht mal eine unbefangene Antwort zu geben:

Es ist nicht verkehrt wenn man die Intuition des users bei der UX nicht komplett vernachlässigt und sie versucht mit in das Design einer Software zu integrieren. Andererseits darf es nicht in ein Korsett gezwängt werden. Wenn TLP bisher so gut gefahren ist dann sehe ich diesen Punkt

Weiß nicht so recht ob sich der ganze Aufwand lohnt.

ähnlich. Vor allem wenn es nur diejenigen betrifft die aktiv in der tlp.conf herumwühlen.

Die Verständlichkeit der Dokumentation, die plötzlich um sehr viele Fallunterscheidungen wächst

Auch das ist nicht zu unterschätzen. Ich gucke gefühlt einmal im Jahr in die Doku und denk "Jesses, is des mehr jeworden oder war das schon immer so?" Aber das liegt in der Natur der Sache und ist ebenso ein Ausdruck einer aktiv in der Entwicklung befindlichen SW. Deswegen verbuche ich das dennoch als positiv in meinem Buch.

Wie die dynamische Umbenennung von der Usern wahrgenommen wird: tlp-stat [-c | --cdiff] würde für alte Konfigurationen die neuen Parameter-Namen anzeigen - das könnte mehr verwirren als die alten Suffixe

Das denke ich eher nicht. --cdiff nutze ich sehr gern und extensiv. Vor allem wer mehrere Maschinen verwaltet und jedes individuell einrichtet, dem hilft diese Option ungemein. Und wer schon so tief in der CLI gräbt, der wird sich schon nicht zieren. Andererseits spräche auch nix dagegen in der nächsten Version Warnhinweise o.a. auszugeben wo immer sie sinnvoll sind.

@linrunner Meiner bescheidenen Erfahrung nach, kann man das auch überdenken. Für ca 80% der user ist tlp direkt nach der Installation gut genug getuned und ready ootb. D.h. die sind nich mal von einem evtl. refactoring betroffen. Und die anderen 20% wird es nicht aus der Rolle bringen. Bisschen DIY gehört bei Open Source Projekten schließlich auch zum guten Ton.

Als Fazit möchte ich auch diesem Statement

Abwärtskompatibilität ist wichtig, darf aber kein Ewigkeits-Feature sein.

beipflichten.
Denn solange dieser kritischer Workaround

Da die Rückwärtskompatibilität zu bestehenden Konfigurationen nicht aufgegeben werden darf, müsste TLP die alten Parameternamen zur Laufzeit den neuen zuordnen. Mit anderen Worten: eure Konfigurationsdateien bleiben unverändert; TLP konvertiert die Parameter bei jeder Ausführung. Ich halte dies für machbar. Andererseits kann ich mir keine zuverlässige, automatisierte Methode vorstellen, um die Konfigurationsdateien umzuschreiben.

bugfrei läuft ist alles ok. Wichtiger als alles andere bleibt die Maintainability des Projekts und die Komplexität in Schach zu halten. Wir user werden schon nachts einschlafen können. Ich find also dass du diesem Punkt zuerst Rechnung tragen solltest, der Rest ist mMn nachranging.