@hexer Ich hab mir auch in den letzten paar Wochen einen "wine-game-manager" gebastelt. Wenn Du Interesse hast, kann ich dir den gerne mal schicken. Ist Bash basiert und läuft im Terminal und nutzt heftigst jq. Bin beim Bash-Scripting allerdings maximal ein Fortgeschrittener also steinige mich nicht, wenn ich Müll gescriptet habe :D ein paar bugs sind auch noch vorhanden. Ich würde es also als Beta bezeichnen... ^^

Naja demnächst werd ich vermutlich eh auf umu umsteigen und meinen game manager entsprechend anpassen

Klasse. Das bedeutet, dass jeder von uns sein eigenes Süppchen gekocht hat. ;-)

Zum Starten verwende ich bash, aber ich installiere automatisch über ein Python-Skript, das spezielle Kommentare aus der bash-Datei ausliest wie Installationsprogrammnamen/Archivnamen, ob dxvk/vkd3d-proton/dgvoodoo2 oder irgendwelche winetricks installiert werden sollen und ein Name zu automatischen Erstellen von Desktop-Dateien und die Steam APPID um Grafiken von Steam auszuleihen damit auf dem Steam-Deck keine Platzhalterboxen erscheinen.

Nochmal zu der xz/liblzma-Hintertür:

Ich habe gestern Abend noch mal etwas mehr zum Thema gelesen und habe dabei extrem dusselige Kommentare gelesen:

Heutzutage bräuchte man gar nichts mehr komprimieren, man hätte ja ganz andere Probleme.

Wer würde denn noch xz verwenden, da zstd viel besser wäre. Und natürlich viel sicherer. Das stand an vielen Stellen, ist aber entweder absichtlich boshaft oder total dämlich, da also genau der Teil von xz der betroffen war oder möglicherweise noch ist, da ja eventuell noch mehr da sein könnte, was noch nicht gefunden wurde.


Auf jeden Fall scheint es so zu sein, dass die Hintertür auf Arch Linux (und Derivaten) gar nicht in liblzma eingebaut wurde, da eine Überprüfung ob ein rpm oder deb-Paket gebaut wird eigentlich fehlschlagen sollte. Deshalb, und wie weiter oben geschrieben dem unmodifizierten sshd, frage ich mich, warum Arch in den Warnungen oft gleichwertig einbezogen wurde.

Zwischendurch habe ich auch gelesen, dass jemand angezweifelt hat, dass das neue Arch Paket sicher(er) sei, da es funktional identisch sei, was natürlich zu erwarten ist, wenn die Hintertür schon vorher nicht eingebaut war.

Klar gerne. Dann können wir vielleicht noch ein bisschen fachsimpeln. ;-)
Das Script, was ich hier verlinkt hatte, ist auch schon nicht mehr aktuell.

Mich treibt ja noch die Verwendung von winemenubuilder und WINEDLLOVERRIDES um.

Ich kriege wine nicht dazu, mir den Pfad der Eigenen Dateien nach $(pwd)/sandbox umzubiegen.
Egal ob ich das mittels WINEMENUBUILDER=/PFAD/ oder über WINEDLLOVERRIDES=winemenubuilder mache.

Irgendeine Idee?

Die vorab vorhanden Links will ich aber auch nicht mit rm und ln umbiegen. Das ist mir zu unelegant. =D

Ich bin da doch auch kein "Pro". ;-)

Sind wir doch mal ehrlich: Fertigsuppen schmecken nicht! =D
Muttis Hausmannskost ist immer noch die beste!

Ich kauf mir ja auch keine Fertigappliances oder "All-In-One-Gaming-PCs" mit Krimesbeleuchtung.

Aha... Sag das mal den Entwicklern von Videospielen mit ihren 100+ GB Spielen. =D
Also ich möchte auf Komprimierungsalgorithmen nicht verzichten. Benutze ich häufig und gerne.

Ich werde die Thematik auch weiterverfolgen. Spannend und beängstigend zugleich. Und ich weiß nicht, was da überwiegt...

Mich wunderte bei meinem Manjaro, dass ich laut pacman wohl eine neue Version installiert habe, aber xz --version mir immer noch die alte Version anzeigte.

Ja, das ist zu erwarten. Falls du die Arch Paketnummern hast, dann ist 5.6.1-2 die explizit neu gebaute Version aus Quelle ohne Hintertür, während 5.6.0-* und 5.6.1-1 die Version aus einer Quelle mit Hintertür wären, wenn sie aus dem tar-Archive erstellt worden wären, was sie aber anscheinend nicht waren – die Version die ich angeschaut habe hat die Quelldaten aus git gezogen. Da war die verantwortliche m4-Datei die aus den Testdaten die Hintertür geholt aber nie drin. Das wäre ein weiteres Argument dafür, dass die Arch-Version nie betroffen war. Zusätzlich zu den anderen Gründen die ich schon genannt hatte.

Ich persönlich finde die mit zstd wäre das nicht passiert Behauptung deutlich interessanter (weil noch unsinniger) als die Kompression braucht keiner Behauptung. Nochmal für andere Leser, die nur überflogen haben: Facebooks zstd verwendet liblzma, also genau die Komponente von xz mit der Hintertür.
Deaktiviere winemenubuilder und erstelle schnell eigene eigene Desktop-Datei

Das sagt zumindest pacman.
Die Ausgabe von xz --version ist aber nur 5.6.1

Davon war auch zu lesen. Deshalb war ich da nicht beunruhigt.

Ja richtig. Hab ich tatsächlich geflissentlich ignoriert.
Könnte auch sein, dass das nur ein sarkastischer Kommentar war.

Mein Einwurf war nur ein kleiner Scherz am Rande. ^__^°

Bin ich da jetzt gedanklich falsch abgebogen?

Das geht doch normalerweise über WINEDLLOVERRIDES, oder nicht?
Genau das passiert eben nicht. Was passiert denn eigentlich dann, wenn ein Spiel seine Speicherdaten normalerweise unter Dokumente/My Games/SpielXY ablegt? Wo landet der Ordner SpielXY dann?
Genau deswegen will ich diese Verknüpfungen umlegen.

Ich will die Verknüpfungen die Wine für die Windows-Ordner anlegt einfach nur woanders haben und das ohne dass ich das in winecfg ändern muss. Eben direkt aus dem Script heraus.
Ich will mir davon nicht mein home-Verzeichnis zumüllen lassen.

Wenn man die Ordner natürlich ganz abschaffen könnte und dafür nur die für das Spiel wichtigen Ordner (wie bspw. MyGames, %APPDATA% etc.) behalten könnte, wäre das noch besser.

Du hast ja normalerweise Verknüpfungen von bspw. Desktop zu ~/Schreibtisch, Dokumente zu ~/Dokumente usw.
Das will ich unterbinden.

drive_c/users/username/Documents/My Games/SpielXY

Wenn du nichts unternimmst, dann ist Documents vermutlich ein Symlink in dein Home-Verzeichnis. Also im Script den Link löschen und einen Ordner anlegen. Dann bleibt der Kram isoliert.

Ich mache als Standard immer Das deaktiviert den Mono/Mozilla-Krempel, winemenubuilder und die meisten Links im Ordner dosdevices. Eigentlich sollten nur noch c: -> ../drive_c und z: -> / übrig bleiben. Wenn du z: entfernst, wird das Installieren von Zeug außerhalb des drive_c Ordners unmöglich, aber du hast etwas mehr Trennung zwischen dem Wine-Prefix und deinem Linux-System. Ich lege automatisch für die Installation temporäre Symlinks in drive_c an.
Das glaube ich nicht. Ich habe das mehrfach gelesen und es wirkte ernst gemeint.

Jepp.

So mach ich das generell immer mit den Ordnern der Spielstände, da ich hierfür in meinem Home-Verzeichnis extra einen Ordner habe.
Ich dachte nur, dass das eleganter geht. Eben direkt über wine. Genau das probiere ich ja die ganze Zeit.
Nach meinem Verständnis müsste er doch dann die Symlinks nicht anlegen, oder? Wenn dem so ist, wo bleibt dann MyGames?
Blöd ist halt auch, dass man das zur Kontrolle nicht in winecfg sieht. Dort kann ich das ja auch eintragen.

Nein. winemenubuilder schreibt in ~/.local/share/ unter anderem MIME-Krempel (u.a. wine notepad für txt-Dateien), Ordner und Einträge fürs Menu usw.

Müsste dann nicht in winecfg im Reiter Desktop-Integration unter der GroupBox MIME-Typen der Haken bei "Manage file and protocol associations" weg sein?

Keine Ahnung. Sollte die GUI auf ein (temporäres) externes Überschreiben von Einstellungen reagieren?

Ich denke, eigentlich nicht. Bei Verwendung von WINEDLLOVERRIDES erscheint es ja auch nicht in winecfg.
Na ja... jedenfalls würde es mich interessieren, wie lutris das macht mit den symlinks. Denn die erscheinen dann geändert in winecfg.

Ha, da ist dir aber ein grober Logikfehler hineingerutscht! Der 08/15-Linuxuser (d.h., der gewöhnliche/durchschnittliche User) ist ja scheinbar doch noch jener, der gerne Computereinstellungen und so Kram biedent, um sich vom Computer bedienen zu lassen. Oder so ähnlich.

Während deine Mom und ich ja scheinbar eher die (ziemlich schlaue) Ausnahme sind: Warum irgendwelchen Einstellungen oder Anpasungen Zeit schenken, wenn man diese Zeit viel besser mit einem feinen Computerspiel verballern kann?!

;-P

- gelöscht -