News Linux-News der Woche: Lossless Scaling für Linux, GuideOS und viel X11

[Kuristina]

Und ja, mir ist die Ironie bewusst, dass ich die Diskussion, durch meine Aussagen nur noch weiter unnötig weitergeführt habe.

Was du jetzt schon wieder machst. ^^ Und wenn du glaubst, das war Stress von mir, dann werden wir beide noch viel Spaß miteinander haben. Frohen Rutsch wünsch ich dir.

 

[DerAnnoSiedler]

@Kuristina Keine Angst, ich nehme selber nichts persönlich und halte sehr viel aus. Ich schreibe - hast du ja auch gemerkt - auch durchaus Sachen direkt, das ist meine ich dann auch weder persönlich noch böse.

Ich hätte nicht mehr geantwortet, wenn es nicht indirekt um den Vorwurf gegangen wäre mit "User abschrecken".
Was ja, Diskussionen wo man hin und her aneinander vorbeireden ist dafür gerade eben nicht zielführend und ja - ihr habt schon irgendwie aneinander vorbeigeredet. Was wohl auch die bessere Formulierung gewesen wäre.

Guten Rutsch!

 

[Ravensberger]

Moin Ihr Lieben,
da habe ich ja etwas angestoßen.

Erst einmal ein ganz dickes Dankeschön an @DerAnnoSiedler .
Zugegeben bin ich noch stark auf die x-tools fixiert und hatte mich einfach bei zwei Tagen Eisregen blind in das Abenteuer geworfen, mit meinem Lenovo X61 Tablet in die Labwc- Welt und dem Wayland Protokoll zu gehen. Bei diesem wunderbaren Gerät friert nämlich X-Server immer wieder ein.

Mit Wayland funktioniert auch der xfce4-screenshooter, allerdings nur zur Gesamtaufnahme des Bildschirms. Jetzt kann ich jetzt auch mit grim & Helfern einen einen benutzerdefinierten Bereich aufnehmen. Genau das hatte ich gesucht!

grim -g "$(slurp)" -t png /home/Ravensberger/screenshot.png

wlr-randr funktioniert zum rotieren ebenfalls prima, zum Beispiel auf 90 Grad nach links:

/bin/wlr-randr --output LVDS-1 --mode 1024x768  --transform 90

Mit einem Status-File als Zwischenspeicher für die aktuelle Position, läßt sich so nun auch wieder die Rotationstaste am Bildschirm belegen.

Wo ich weiterhin nicht weiterkomme, ist der Treiber für den Wacom Bildschirm, dass man auch mit dem Stift des Gerätes hierauf schreiben und absetzen kann. Dieses geschieht unter x11 mit xwacom, etwa so:

xsetwacom set "Wacom Serial Penabled Pen stylus" Rotate $T

Das wäre eigentlich Thema für einen eigenen Strang gewesen. Für dieses Jahr wollen wir es aber gut sein lassen.

Genießt das Silvester und kommt gut ins neue Jahr!

 

[Meta.Morph]

Es ist verdammt smooth und schnell

Wie soll man "smoothness" messen? Das mit dem schnell? Puh... Ich müsste da echt ne Stoppuhr zur Hand nehmen und dann würde immer noch offen sein, ob ich beim Drücken nicht einfach die Millisekunden zwischen den Sekunden verpasse...

Mein System wurde nicht spürbar schneller, würde ich behaupten. Mein System ist knapp 2 Jahre alt und ich hatte EndeavourOS.

So ein Geschwindigkeitstest würde mich echt interessieren und ab welcher Hardwareconfig die Veränderungen des Team sich überhaupt spürbar (nicht nur im Millisekundenbereich) wahrnehmen lassen.

Auf mich wirkt das bislang eher als Hype, den viele Nachplappern.

Und nicht Falsch verstehen. Ich hab keine Präferenzen. Eher im Gegenteil. Ich finde die Snapper Installation fortschrittlich.

 

[mibbio]

Mein System wurde nicht spürbar schneller, würde ich behaupten. Mein System ist knapp 2 Jahre alt und ich hatte EndeavourOS.

So ein Geschwindigkeitstest würde mich echt interessieren und ab welcher Hardwareconfig die Veränderungen des Team sich überhaupt spürbar (nicht nur im Millisekundenbereich) wahrnehmen lassen.

CachyOS gibt selber zwischen 5-20% Performancegewinn an, durch die gezielt Kompilierung für x86_64v3 statt generischem x86_64(v1).

https://wiki.cachyos.org/features/optimized_repos/

Entsprechende Benchmarks mit einem Ryzen 9950X gibt es bspw. von Phoronix. Da hebt sich CachyOS gar nicht so besonders von anderen Distributionen ab und liegt teils sogar hinter anderen.

Explizit für x86_64v3 (oder v4) zu kompilieren und damit verbundenes aggressiveres Optimieren durch den Compiler hat aber auch nur dann einen nennenswerten Mehrwert, wenn die Anwendung zur Laufzeit nicht ohnehin schon selbstständig die moderneren Befehlssätze abfragt und nutzt. Nutzt die Anwendung die CPU und deren Befehlssätze ohnehin schon selber optimal, sorgt x68_64v3 als Compile-Target im Wesentlichen nur dafür, dass die Laufzeit-Check stärker wegoptimiert werden. Da geht der Grenznutzen dann aber tendentiell gegen Null, bei gleichzeitigem Verzicht auf Kompatiblität zu älteren CPU-Generationen.

Dazu nutzt CachyOS default den BORE CPU-Scheduler, der etwas flinker auf Lastwechsel reagiert. Aber der steigert nicht die prinziepielle Performance des Systems, sondern es fühlt sich nur etwas flotter an, weil die abgerufene Leistung nen paar Millisekündchen schneller anliegt.

Es werden auch noch 2-3 andere optimierende Compilerflags genutzt und hier und dort ein paar Patches, die (noch) nicht regulärer Bestandteil des Kernel- bzw. Programmcodes sind und es werden ein paar Systemparameter mit sysctl anders eingestellt.

All das vollbringt aber am Ende keine Wunder, sondern der Mehrwert hängt stark vom konkreten Workload ab und wie gut eine Anwendung schon von sich aus optimiert ist. In den vielen Situationen ist der Performancegewinn in der Praxis minimal bis kaum existent.

 

[dev/random]

Der Effekt ist sehr stark von Deiner individuellen Hardware, Software und Nutzung abhängig.
Auch wenn irgendwo durchschnittliche oder maximale Performance-Gewinne geschätzt werden, kann man daraus kaum etwas für das eigene System ableiten.

Beispiel: Mein Gaming-System läuft mit einer 5800X3D CPU. Die ist Zen3 Architektur und hat kein AVX512 sondern unterstützt maximal x86-64-v3. Alle höheren Compiler-Optimierungen sind hier einfach Zeitverschwendung bzw. sogar kontraproduktiv. Und auch bei Intel CPUs ist die Architektur-Unterstützung keineswegs so eindeutig. Die Warnungen würde ich schon ernst zu nehmen, bevor ich mein ganzes System umstelle.

Beispiel 2: Die Compiler-Optimierung kann zwar die Performance der damit kompilierten Programme erhöhen, aber auch nur das. Für Software aus anderen Quellen (flatpak, snaps, appimage, docker, VMs, proprietäre Binaries, ...) hat es keinen direkten Effekt, höchstens vielleicht Seiteneffekte durch eine laufzeit-optimierte Umgebung. Windows-Spiele werden also nicht direkt von einer Compiler-Optimierung profitieren, während die wine/proton Schicht durchaus schneller werden kann.

 

[mibbio]

während die wine/proton Schicht durchaus schneller werden kann.

Wobei man die von CachyOS optimierte (Compilter-Flags, zusätzliches Patches) von Proton prinzipiell auch mit jeder anderen Distribution verwenden kann.

Einfach sowas wie ProtonPlus installieren, worüber man die Protonversionen/-varianten für Steam, Heroic, Lutris und die jeweiligen Spieleinstellungen zentral verwalten kann.