Zur Verteidigung von LibreWolf
Wednesday, 2. November 2022
Sören kritisiert in seinem Blog LibreWolf, eine dieser alternativen Firefoxkonfigurationen. Er hat nicht völlig unrecht mit seiner Kritik, ich möchte aber zweien seiner Argumente dagegenhalten.
Das fehlende Projektimpressum
Sören schreibt:
Nun wirbt also ein Projekt um Vertrauen, welches nicht einmal ein Impressum auf der eigenen Website hat. Die Argumentation, dass im Land des Betreibers ggfs. keine gesetzliche Impressumspflicht besteht, könnte zu kurz greifen, da hier ein Produkt auch innerhalb der Europäischen Union angeboten wird. Letztlich schafft es aber auch vollkommen unabhängig von der rechtlichen Perspektive nicht unbedingt Vertrauen, wenn darauf verzichtet wird. Denn auch wenn es sich hier um ein Community-Projekt handelt, so muss es am Ende des Tages eine Person geben, welche gesamtverantwortlich für den Browser sowie Inhalte der Website ist.
Er verkennt hier in welcher Softwarewelt wir uns bewegen. Jeder von uns benutzt täglich Software, dessen Autor wir nicht kennen. Ist das tatsächlich mal anders, benutzen trotzdem die Entwickler der Software Abhängigkeiten deren Autor sie nicht kennen. Die FOSS-Welt ist auf eine andere Basis aufgestellt als die einer Internet-Impressumspflicht, einer rein deutschen Erfindung deutscher Weltregulierungsbürokraten. Schon bei Webseiten ist diese lächerlich, bei FOSS-Softwareprojekten völlig unbekannt. Klar, viele große Softwareprojekte lassen sich einzelnen Firmen oder speziell für sie gegründeten Vereinigungen zuordnen, die Regel ist das aber nicht.
Dementsprechend ist es keinesfalls so, dass für Browser oder Webseite des Projekts eine einzelne Person gesamtverantwortlich sein muss. Selbst wenn gewisse Juristen und Politiker das gerne so hätten.
Nebenbei, eine gesetzliche Impressumspflicht für solch eine private Hobbyseite besteht auch in Deutschland nicht. Edit: Diese meine Auffassung wird in den Kommentaren von fachkundiger Seite allerdings bestritten. Ich bleibe dabei, dass ein Projekt an solchen juristisch-bürokratischen Maßstäben zu messen keine gewinnende Strategie ist.
Das harmlose DRM
Sören schreibt:
Interessant ist auch die Begründung, mit der LibreWolf standardmäßig Digital Rights Management (DRM) abgeschaltet hat: Dies sei eine Limitierung der Nutzer-Freiheit. Das ist natürlich völliger Quatsch, denn im Gegenteil erlaubt DRM dem Nutzer den Konsum von Filmen, Serien und Sportveranstaltungen, sowohl kostenlos als auch kostenpflichtig, die anders überhaupt nicht angeboten werden könnten und was für den Nutzer auch überhaupt keinen Nachteil besitzt, während es das LibreWolf-Projekt ist, welches sich hier eine standardmäßige Einschränkung seiner Nutzer anmaßt – wohlgemerkt während gleichzeitig groß mit Freiheit geworben wird.
Die Aktivierung von DRM (Digital Restriction Management) in Browsern wie Firefox ist keinesfalls ohne Nachteile für die Nutzer, denn es propagiert die Nutzung dieser Technologie. Mit DRM aber kontrollieren Firmen, was die Menschen mit ihren Rechnern machen können. Dann werden Bücher aus der Ferne gelöscht, das Abspielen auf dem gewünschten Anzeigegerät verboten, das Anfertigen von Screenshots für Kritiken verhindert, das völlig legale Verleihen unterbunden; Kurz: Jedwede nicht komplett vorgesehene Nutzung der Inhalte wird verhindert. Als Firefox damals DRM aktivierte war es eine Niederlage für die Freiheitsrechte von uns allen, es in einem relevanten Browser nicht aktivieren zu können wirkte vorher gegen die weitere Verbreitung.
Natürlich kann jeder für sich abwägen, ob in einem bestimmten Kontext wie z.B. für Netflix das DRM nicht doch akzeptabel ist. Aber das sollte definitiv ein Opt-In und nicht standardmäßig an sein und ist wie ausgeführt nicht grundsätzlich eine nachteilslose Geschichte.
Das waren nur die zwei Argumente, die bei mir den größten Widerspruch provozierten. Mit den anderen Argumenten haben ich weniger Probleme, aber die Gesamtkritik findet mein Gefallen nicht.
Denn ich denke zwar insgesamt auch, dass ein Projekt wie LibreWolf natürlich Nachteile hat. Gerade Updates etwas später zu erhalten ist nicht ideal. Dazu laufen solche Projekte tatsächlich in die Gefahr, Sachen zu deaktivieren, die im Großen und Ganzen positiv sind. In diese Richtung geht der Großteil Sörens Kritik. Aber sie ist mir zu negativ, zu einseitig, das Projekt wegen seiner vermeintlichen Gefährlichkeit sogar nicht zu Verlinken empfinde ich als überzogen und wirkt auf mich kindisch. Denn erstmal ist es doch eine gute Sache, wenn alternative Konfigurationen von Firefox ausprobiert werden, wenn es ein Korrektiv für Mozillas teils eben durchaus fragwürdige Entscheidungen gibt.
Das ist immerhin die Firma, die bei der Überarbeitung der Androidversion Erweiterungen unter großem Protest deaktivierte und forkverhindernd ihre rasche Wiedereinführung versprach, was mittlerweile jahrelanges Verschleppen als Lüge entlarvt hat und nichtmal den eigenen Entwicklern erklärt wird. Besonders bei einem solchen Akteur ist Diversität eine Stärke, so ist auch LibreWolfs Existenz zu begrüßen. Ich vermute daher auch, dass die heftige Kritik weniger gegen das Projekt geht als gegen das durch das Projekt durchscheinende negative Bild von Mozilla – ob dem Autor das jetzt bewusst ist oder nicht.
Hacktoberfest 2022 und meine vier Paketupdates für Void Linux
Monday, 10. October 2022
Das Hacktoberfest belohnt Beiträge zu FOSS-Projekten, Ausrichter ist der US-Hoster Digitalocean. Void Linux macht dabei mit und ich empfand deren Beschreibung als sehr einladend: Die Ziele sinnvoll, klarer Einstiegspunkt und alle wichtigen Informationen wurden verlinkt. Wie war es dann, vier verwaiste Pakete für alle Void-Nutzer zu aktualisieren?
Das Prinzip
Das Hacktoberfest funktioniert so: Man meldet sich auf der Webseite an und gibt Leserechte auf den Github/Gitlab-Account. Projekte müssen über ihre Projektbeschreibung ihre Teilnahme signalisieren. Kommen dann im Projektzeitraum vier Pull-Requests an, bekommt der Teilnehmer ein T-Shirt oder es wird in seinem Namen ein Baum gepflanzt (beschränkt auf die 40.000 schnellsten erfolgreichen Teilnehmer). Der Fortschritt wird auf der Webseite in einer Übersicht angezeigt.
Void Linux hat auf seiner Webseite eine News veröffentlicht und da klar beschrieben, was sie brauchen:
- Updates für verwaiste Pakete, und zwar lieber als Rezepte für neue Pakete
- Upstream-Patches für Pakete, die nicht auf allen unterstützten Plattformen kompilieren
- Fixes für ihre eigene Infrastruktur
- Erweiterung der Dokumentation
Sie wollen also die Aktion nutzen um die anfallende Arbeit zu erleichtern, das fand ich super. Updates für verwaiste Pakete einzubringen sei zudem recht simpel.
Darüber kann man streiten, aber die Dokumentation dazu half auf jeden Fall. Zuerst gibt es eine Updateliste, die dort gelisteten Updates für Pakete von orphan@voidlinux.org sind die Ziele. Dann gibt es die Dokumentation, die etwas verteilt alles weitere erklärt: Das Readme des Paketrepos, die Anleitung und besonders hilfreich die Contributing-Hinweise.
Das Grundprinzip erklärt am besten die Readme: Klone das Git-Repo, führe darin ./xbps-src binary-bootstrap aus um Voids Paketinfrastruktur zu bauen. Aber wer Änderungen einbringen will liest sich besser durch Contributing, das erklärt neben dem Git-Drumherum das Vorgehen für Paketupdates: Editiere die Rezeptdatei ./srcpkgs/Paketname/template des Pakets (was oft einfach nur eine Anhebung der Versionsnummer sein wird), aktualisiere die Prüfsumme mit xgensum -i Paketname, baue das Paket mit ./xbps-src pkg <package_name>, dann installiere es mit xbps-install --repository hostdir/binpkgs <package_name>. Testen und einen PR mit einem einzelnem Commit an void senden. Das mit dem einen Commit wird oft bedeuten mit git rebase Commits zusammenzufügen, vor allem wenn nachträgliche Änderungen gefordert werden (was bei mir passierte).
Bei ihrem Github sind automatisierte Tests eingerichtet, die einen Syntaxcheck über die Rezeptdatei laufen lassen und zudem schauen, ob das Paket wirklich gebaut werden kann. Die sollten durchlaufen, ansonsten am besten direkt reagieren und den Fehler korrigieren.
Das musste ich teils auch bei meinen folgenden Paketupdates machen.
Update 1: memcached 1.6.10 -> 1.6.17
Memchached ist nicht Memcache, trotzdem fiel mit der Name wegen seiner Webentwicklerrelevanz auf. Das Update war nicht ganz so einfach: Erst wollte das Paket nicht bauen, dann wusste ich nicht wie ich es testen könnte.
Ich setzte also die Versionsnummer auf 1.6.17 und der Paketbau warf einen Fehler:
configure.ac:65: error: possibly undefined macro: AS_IF
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
Zum Glück war dafür ein Fehlerbericht bereits im memchached-Github, pkg-config würde gebraucht. Das zum Template hinzugefügt und der Bau lief durch. Hier als Beispiel ein Sreenshot der Änderungsübersicht, damit deutlich wird um wie wenige Codezeilen es letzten Endes geht:
Aber wie testet man memcached ohne herumliegenden Programmcode? Mit echo und nc ist die Antwort, wobei ich bei mir echo -e schreiben musste.
Daraufhin ging der PR durch.
Update 2: ruby-mime-types 3.3 -> 3.4.1
Eigentlich wollte ich ruby-httparty aktualisieren, aber das stolperte über diese Abhängigkeit. Das Gem mime-types war zu alt, um mit einer aktuellen Ruby-Version zu funktionieren. Ich musste da an mein altes Projekt music-streamer denken, das die MIME-Daten ausgelesen hat, wobei ich damals ruby-filemagic benutzte.
Hier war nur die Frage wie das Gem getestet werden kann, denn der Bau der neuen Version lief direkt durch. Die Antwort war irb, der Testcode entstammt der Projektreadme:
require 'mime/types' MIME::Types['text/plain']
Im PR kam dann nur der Vorschlag, die Changelog-Datei zu verlinken.
Update 3: ruby-mime-types-data 3.2019.1009 -> 3.2022.0105
Ich fand es naheliegend, ruby-mime-types-data direkt mitzuaktualisieren. So ein Datenpaket sollte keine Abhängigkeiten haben und ist daher einfach, aber es vermeidet im Zweifel Bugs in anderen Paketen wenn die Datenbank aktuell ist. Der Test war genau wie bei ruby-mime-types (das dieses Paket als Datenquelle lädt), nur dass beide neue Versionen installiert waren.
Im PR lief ich nur in ein Miniproblem mit einem Leerzeichen nach der Versionsnummer, was xlint nicht mochte. Das konnte ich mit commit -v --amend und einem folgendem git push --force reparieren, ohne rebase, wobei ich beim ersten mal vergessen hatte meine Änderung vorher auch mit git add sichtbar zu machen.
Update 4: minitube 3.9.1 -> 3.9.3
Ich hatte mir vor einer Weile mal einige Linux-Youtubeclients angeschaut, da fiel mir minitube direkt auf. Dem Versionsummersprung entsprechend war es ein kleines Update und lief problemlos durch, ich testete hier auch wieder die ARM-Crosskompilierung, was bei Void mit ./xbps-src -a armv6l pkg minitube einfach anzuleiern ist.
Funktionstest bei so einem Anwenderprogramm war dann viel einfacher als bei memcached, ich startete das Programm und schaute ob Videos abgespielt werden konnten.
Das wurde dann dieser PR.
Ein paar Gedanken zum Schluss: Das Hacktoberfest gefiel mir gut. Die früheren Probleme scheinen ausgeräumt. Natürlich wäre es noch cooler jemanden neu zur FOSS-Welt zur Teilnahme zu bringen, aber auch ich empfand den vom Void-Projekt bereitgestellten klaren Einstiegspunkt hilfreich. Manchmal ist ein klares "Wir wollen wirklich Hilfe, und zwar genau diese" sehr überzeugend.
Aber ohne mich zu sehr beweihräuchern zu wollen: Mir hat das auch nochmal vor Augen geführt, wie groß die Hürde eigentlich ist. Git mit seinen Konzepten ist schon nicht simpel, wenn dann noch rebase und Force-Push dazukommen wird es nicht einfacher. Ich erinnere mich zum Beispiel, dass mir sehr lange schlicht nicht klar war wie man PRs überhaupt aktualisieren kann, als ich git schon längst für meine eigene Versionsverwaltung nutzte. Jetzt scheint es simpel, damals fehlte mir einfach das mentale Modell dafür. Davon abgesehen, das Prüfen durch andere Entwickler machte mich anfangs nervös, alternativ genervt, wenn PRs ignoriert wurden (letzteres gilt immer noch, trifft mittlerweile aber weniger hart und bei Serendipity habe ich Vermeidungsstrategien entwickelt). Und das ist eine Hürde, die fast jede Code-Beisteuerung nehmen muss. Selbst man nicht direkt Linux-Paketmaintainer spielen will. Projekte tun gut daran möglichst viel davon zu dokumentieren, selbst wenn es redundant wirkt, einen ganzen Monat für diese Aktion zu geben ist ebenfalls angemessen.
Wie schwer bei Void das Aktualisieren von Paketen dann wirklich war hing natürlich stark vom Paket und vom jeweiligen Updatefehler ab. Ich wäre zum Beispiel ohne den existierenden Fehlerbericht über die nichtssagende Fehlermeldung bei memcached nie auf pkg-config als fehlende Abhängigkeit gekommen, und das obwohl ich pkg-config schon selbst bei simdock eingesetzt habe. Wer kein Ruby-Entwickler ist könnte das Testen vom Ruby-Gems schwierig finden. Überhaupt, dass man beim Kompilieren Fehlermeldungen wirklich lesen und interpretieren kann hat mir vor vielen Jahren Unki auf UbuntuUsers.de erst erklären müssen. Es baut alles aufeinander auf…
Der Blickwinkel macht für mich dann das Hacktoberfest nochmal wertvoller – wenn es bei einigen der Teilnehmern ein paar der benötigten Grundlagen schafft, ist das einfach eine gute Sache. Man kann es auf zwei Ebenen zwar auch kritisieren: Der Gamification-Ansatz ist manipulierend, via den T-shirts extrinsische Motivation einzuführen könnte intrinsische zerstören. Aber ich glaube, der Anreiz an Projekte die Unterstützbarkeit klar zu beschreiben wiegt das auf, und ein kleiner Motivationsanschub durch eine Aktion im Jahr dürfte auch langfristig wenig schädlich sein.
Mehr FPS für lau unter Linux: Proton, FSR und vkBasalt
Monday, 19. September 2022
Wer die technische Entwicklung bei Spielen nicht genau verfolgt könnte es verpasst haben, doch tatsächlich sind die Upscale-Techniken von AMD, Nvidia und jetzt Intel revolutionär. Mit ihnen laufen Spiele intern auf einer kleineren Auflösung – also z.B. 1477x831 – und die Grafikkarte skaliert das Bild dann eigenständig auf die Zielauflösung hoch – hier 1920x1080. Und die Ergebnisse sehen toll aus. Ursprünglich wurde dieser Ansatz als Lösung präsentiert um 4K-Auflösungen erreichbarer zu machen, doch mir ist das obere Szenario viel sympathischer. Denn so werden alte Grafikkarten entlastet, die dann auf einmal moderne AAA-Spiele besser bewältigen können. Das Hochskalieren mittels der GPU ist praktisch kostenlos, das Herunterregeln der internen Auflösung spart Unmengen an Aufwand.
Damit das perfekt läuft muss das Spiel diese Techniken unterstützen. Doch unter Linux haben sich Entwickler auf das freie FSR gestürzt, das Upscaling von AMD. Dessen erste Version lässt sich an jedes Spiel anheften! Die Ergebnisse sind teilweise erstaunlich gut, zumindest wenn man etwas nachhilft. Und da kommt vkBasalt ins Spiel.
In Kurz
Installiere Proton-GE und vkBasalt sowie optional Mangohud. Benutze für vkBasalt diese Konfiguration. Starte ein Windowsspiel so:
mangohud ENABLE_VKBASALT=1 WINE_FULLSCREEN_FSR=1 WINE_FULLSCREEN_FSR_MODE=ultra %command%
Setze die Auflösung im Spiel auf die FSR-Startauflösung für die native Zielauflösung deines Monitors (Tabelle hier). Fertig, das Spiel läuft schneller als zuvor.
Die ausführliche Anleitung folgt.
FSR aktivieren
Doch erstmal muss man FSR überhaupt ankriegen. Auf dem Steamdeck hat Valve das mitgeliefert, im regulären Proton nicht. Dafür braucht es bisher noch eine alternative Protonvariante, nämlich GloriousEggrolls Proton. Die Installation ginge so:
- Download a release from the Releases page.
- Create a ~/.steam/root/compatibilitytools.d directory if it does not exist.
- Extract the release tarball into ~/.steam/root/compatibilitytools.d/.
- tar -xf GE-ProtonVERSION.tar.gz -C ~/.steam/root/compatibilitytools.d/
- Restart Steam.
- Enable proton-ge-custom.
Doch ist das unnötig kompliziert, wenn ProtonUp-Qt das mit ein paar Klicks machen kann. Also: Zieh dir das AppImage davon, mach es ausführbar, lass es Proton-GE installieren.
Danach kann das in den Einstellungen von Steam unter Steam Play für alle Spiele aktiviert werden, oder du setzt die Protonversion für das jeweilige Spiel unter "Kompatiblität".
Um jetzt ein Spiel mit FSR zu starten müssen die Startparameter gesetzt werden. Rechtsklick in Steam aufs Spiel, Eigenschaften, dann sind die Startoptionen direkt rechts. Schreibe dort:
WINE_FULLSCREEN_FSR=1 WINE_FULLSCREEN_FSR_MODE=ultra %command%
Wenn jetzt das Spiel gestartet wird läuft alles normal, FSR tut noch nichts. Dafür muss erst die Auflösung gewechselt werden. Durch den Start samt FSR-Befehl sollte in den Einstellungen jetzt eine passende auftauchen. Bei meiner 1080p-Auflösung als Ziel ist das 1477x831, bei 1440p oder 4K als Ziel entsprechend mehr. Die beste Liste dafür findet sich hier. Wird jetzt diese Auflösung gewählt greift FSR. Das Bild sieht etwas ausgewaschener aus, aber viel besser als wenn die Auflösung nicht automagisch hochskaliert werden würde.
vkBasalt aktivieren
Diesem ausgewaschenem Bild kann vkBasalt auf die Sprünge helfen. Das Programm zeichnet Filter über die Ausgabe von Programmen. Besonders interessant für uns, dass es das Bild mittels zweier Methoden nachschärfen kann, und dass es nochmal zwei Kantenglättungsfilter kennt.
vkBasalt kann manuell installiert werden, das ginge so:
git clone https://github.com/DadSchoorse/vkBasalt.git cd vkBasalt meson --buildtype=release --prefix=/usr builddir ninja -C builddir install
Wieder sollte das nicht nötig sein, es ist in einigen Repos bereits vertreten und kann daher direkt über den Paketmanager installiert werden. Bei mir mit Void Linux:
sudo xbps-install vkBasalt
Die Konfiguration fehlt aber noch. Geht auch per Spiel, was in der Readme erklärt wird, ich würde stattdessen die Datei $HOME/.config/vkBasalt/vkBasalt.conf anlegen und hiermit füllen:
#effects is a colon seperated list of effect to use #e.g.: effects = fxaa:cas #effects will be run in order from left to right #one effect can be run multiple times e.g. smaa:smaa:cas #cas - Contrast Adaptive Sharpening #dls - Denoised Luma Sharpening #fxaa - Fast Approximate Anti-Aliasing #smaa - Enhanced Subpixel Morphological Antialiasing #lut - Color LookUp Table effects = smaa:dls reshadeTexturePath = "/path/to/reshade-shaders/Textures" reshadeIncludePath = "/path/to/reshade-shaders/Shaders" depthCapture = off #toggleKey toggles the effects on/off toggleKey = Home #enableOnLaunch sets if the effects are emabled when started enableOnLaunch = True #casSharpness specifies the amount of sharpning in the CAS shader. #0.0 less sharp, less artefacts, but not off #1.0 maximum sharp more artefacts #Everything in between is possible #negative values sharpen even less, up to -1.0 make a visible difference casSharpness = 0.3 #dlsSharpness specifies the amount of sharpening in the Denoised Luma Sharpening shader. #Increase to sharpen details within the image. #0.0 less sharp, less artefacts, but not off #1.0 maximum sharp more artefacts dlsSharpness = 0.5 #dlsDenoise specifies the amount of denoising in the Denoised Luma Sharpening shader. #Increase to limit how intensely film grain within the image gets sharpened. #0.0 min #1.0 max dlsDenoise = 0.8 #fxaaQualitySubpix can effect sharpness. #1.00 - upper limit (softer) #0.75 - default amount of filtering #0.50 - lower limit (sharper, less sub-pixel aliasing removal) #0.25 - almost off #0.00 - completely off fxaaQualitySubpix = 0.75 #fxaaQualityEdgeThreshold is the minimum amount of local contrast required to apply algorithm. #0.333 - too little (faster) #0.250 - low quality #0.166 - default #0.125 - high quality #0.063 - overkill (slower) fxaaQualityEdgeThreshold = 0.1 #fxaaQualityEdgeThresholdMin trims the algorithm from processing darks. #0.0833 - upper limit (default, the start of visible unfiltered edges) #0.0625 - high quality (faster) #0.0312 - visible limit (slower) #Special notes: due to the current implementation you #Likely want to set this to zero. #As colors that are mostly not-green #will appear very dark in the green channel! #Tune by looking at mostly non-green content, #then start at zero and increase until aliasing is a problem. fxaaQualityEdgeThresholdMin = 0.0312 #smaaEdgeDetection changes the edge detection shader #luma - default #color - might catch more edges, but is more expensive smaaEdgeDetection = luma #smaaThreshold specifies the threshold or sensitivity to edges #Lowering this value you will be able to detect more edges at the expense of performance. #Range: [0, 0.5] #0.1 is a reasonable value, and allows to catch most visible edges. #0.05 is a rather overkill value, that allows to catch 'em all. smaaThreshold = 0.05 #smaaMaxSearchSteps specifies the maximum steps performed in the horizontal/vertical pattern searches #Range: [0, 112] #4 - low #8 - medium #16 - high #32 - ultra smaaMaxSearchSteps = 32 #smaaMaxSearchStepsDiag specifies the maximum steps performed in the diagonal pattern searches #Range: [0, 20] #0 - low, medium #8 - high #16 - ultra smaaMaxSearchStepsDiag = 16 #smaaCornerRounding specifies how much sharp corners will be rounded #Range: [0, 100] #25 is a reasonable value smaaCornerRounding = 25 #lutFile is the path to the LUT file that will be used #supported are .CUBE files and .png with width == height * height lutFile = "/path/to/lut"
Die Steam-Startparameter des Testspiels ergänzen wir nun ebenfalls um ENABLE_VKBASALT=1, sodass sie so aussehen:
ENABLE_VKBASALT=1 WINE_FULLSCREEN_FSR=1 WINE_FULLSCREEN_FSR_MODE=ultra %command%
Die Home-Taste auf der Tastatur deaktiviert nun vkBasalt, der Effekt sollte deutlich sichtbar sein, nochmal Home aktiviert es wieder. Verschwunden ist das ausgewaschene der Standard-FSR-Hochskalierung.
MangoHud, optional
Wer den Bildunterschieden noch nicht ganz traut kann das ganze mit MangoHud überprüfen. Auch das war bei mir in den Quellen:
sudo xbps-install MangoHud
Die manuelle Installationsanleitung spare ich mir hier, sie ist ausführlich auf der Githubseite erklärt, samt vorkompilierten Releasedateien.
Auch Mangohud will konfiguriert werden. Setze in die $HOME/.config/MangoHud/MangoHud.conf diesen Inhalt:
### MangoHud configuration file ### Display the current GPU information gpu_stats ### Display the current CPU information cpu_stats ### Display FPS and frametime fps frametime ### Display the frametime line graph frame_timing ### Display GameMode / vkBasalt running status vkbasalt ### Display the current resolution resolution ### Disable / hide the hud by default no_display ################ WORKAROUNDS ################# ### Options starting with "gl_*" are for OpenGL ### Specify what to use for getting display size. Options are "viewport", "scissorbox" or disabled. Defaults to using glXQueryDrawable # gl_size_query=viewport ### (Re)bind given framebuffer before MangoHud gets drawn. Helps with Crusader Kings III # gl_bind_framebuffer=0 ### Don't swap origin if using GL_UPPER_LEFT. Helps with Ryujinx # gl_dont_flip=1 ################ INTERACTION ################# ### Change toggle keybinds for the hud & logging # toggle_hud=Shift_R+F12 # toggle_fps_limit=Shift_L+F1 # toggle_logging=Shift_L+F2 # reload_cfg=Shift_L+F4 # upload_log=Shift_L+F3
Das ist fast Standard, aktiviert aber die Optionen zur Erkennung von vkBasalt und der Auflösung. Noch die Startparameter anpassen:
mangohud ENABLE_VKBASALT=1 WINE_FULLSCREEN_FSR=1 WINE_FULLSCREEN_FSR_MODE=ultra %command%
Jetzt erscheint nach Druck auf rechtem Shift + F12 links oben eine Box, die neben den Frametimes und FPS auch die Auflösung anzeigt (was bei aktiviertem FSR also 1920x1080 bzw die Zielauflösung ist, selbst wenn das Spiel intern eine geringere gesetzt hat) und ob vkBasalt an ist. Shift_R + F12 versteckt die Box wieder.
Diskussion der Bildqualität
Wie gut ist jetzt noch das Bild? Ich habe hier mit Metro Exodus ein paar Vergleichsbilder gemacht. Zuerst einmal ist das Ziel die tolle 1080p-Qualität, wobei das nichtmal die hohen Einstellungen sind:
In meiner (recht einfachen) Testszene schwankte mein System hiermit zwischen 70 und 94 FPS.
Mit FSR im Ultra-Modus, also intern 1477x831, sieht das ganze leider viel weniger scharf aus:
Dafür sind die FPS besser, 80 bis 106 FPS sah mein Test. Und das ist die geringste FSR-Stufe, die anderen würden die interne Auflösung weiter verringern und die Performance verbessern.
Und schließlich das Bild mit Ultra-FSR samt vkBasalt:
Das erreicht nicht ganz die Qualität der nativen 1080p-Auflösung. Nicht, dass es nicht ähnlich scharf wäre. Aber FSR produziert eine Abrundung von Linien (gerade im hier nicht sichtbaren HUD) und einen grauen Körnereffekt über dem Bild. Das Schärfen mittels vkBasalt wirkt da leider nicht gegen. Trotzdem wertet vkBasalt das Bild wesentlich auf, die wahrnehmbare Unschärfe ist weg.
Die Performance mit vkBasalt war nur ein bisschen schlechter, die FPS lagen bei 80 bis 100.
Ich wollte hier zum einen FSR mit vkBasalt vorstellen. Gerade die Kombination von FSR mit vkBasalt als Schärfefilter sah ich noch nicht so oft diskutiert, dass Linux hier Spielern eine tolle Tuningoption gibt soll nicht untergehen. Der Umweg über Proton schafft unerwartete Möglichkeiten um Spielen einen gar nicht mal so kleinen Schubs zu geben. Immer noch auf Kosten der Grafikqualität, zugegeben, aber je nach Spielertyp ist es das wert.
Aber mich interessieren besonders auch Fehler in meiner Konfiguration. Gibt es zu vkBasalt sogar gute Alternativen? Wäre bei dessen Einsatz die Kombination der beiden Schärfefilter cas und dls sinnvoll? Sollte FXAA statt SMAA benutzt werden? Ich habe natürlich schon einiges auspobiert, aber bin keineswegs sicher, dass die Konfiguration oben die optimale ist. Nur dass sie ein guter Startpunkt ist, davon bin ich überzeugt.
Als Fazit reizt mich auch der Gedanke, dass dieses jetzt schon interessante Ergebnis die erste Version von FSR nutzt. DLSS 2.0, FSR 2.0 und XeSS sind nochmal deutlich besser. Wenn es irgendwie gelingen würde, sowas wie XeSS auch ohne Entwickleraufwand nutzbar zu machen und dann mit jedem Spiel kombinieren zu können...
DivestOS bei sustaphones
Wednesday, 14. September 2022
DivestOS ist ein Fork von LineageOS. Das Ziel: Gerade auch ältere Telefon mit einem möglichst sicherem Android ausstatten, sodass Nutzer die Kontrolle über ihr System bewahren. Dabei ist ein Fokus auf FOSS Teil der Projektphilosophie, sodass z.B. proprietäre Blobs an vielen Stellen entfernt werden.
Das passt natürlich perfekt zu sustaphones, meinem ROM-Finder für möglichst reparierbare Telefone. Nachdem ich über das ROM las kontaktierte ich daher das Projekt per Reddit. Ergebnis: DivestOS konnte gelistet werden. Der Parser ist zwar etwas komplexer als ideal (weil die Daten nicht in einem Rutsch heruntergeladen werden können), aber es waren doch alle notwendigen Informationen verfügbar – welches Gerät von welcher Version unterstützt wird, wobei bei diesem Projekt auch der Grad der Unterstützung (von "kaputt" bis "getestet, funktioniert") berücksichtigt werden musste.
Die Reihenfolge der Geräte auf der Webseite wird durch die neue Alternative durchaus etwas verändert, obwohl das als Lineage-Fork nicht unbedingt zu erwarten war. Doch werden teils neue Smartphones wie das FP4 offiziell unterstützt, wo bei LineageOS die Unterstützung noch fehlt, und werden einige alte Telefone wie das HTC One (M8) mit einer aktuellen Androidversion versorgt, die von anderen Projekten längst ignoriert werden.
Ich freue mich über das Projekt sowie über die erhaltene Möglichkeit, der Webseite eine weitere Alternative hinzuzufügen.
Lüftersteuerung mit fan2go
Wednesday, 20. July 2022
Kommt ihr gut durch die Hitze? Wenn während der Hitzewelle der PC zu sehr brummt könnte eine Anpassung der Lüftersteuerung angesagt sein. Das Programm fan2go ist eine relativ neue Alternative zum altgedienten fancontrol, die leichter zu benutzen ist und ein paar Probleme bezüglich der sich ändernden Lüfter-Indexierung ausräumen will.
Warum sollte man solch ein Programm nutzen und nicht einfach die Fankurve im BIOS festlegen? Tatsächlich sollte man letzteres vorziehen. Aber manchmal hat das Mainboard diese Funktion einfach nicht, oder sie funktioniert nicht richtig. So war es bei mir; Ich hatte den Lüfter des Prozessorkühlers auf 12% runtergeregelt, trotzdem rödelte er relativ laut. Ich wunderte mich darüber ewig, bis ich jetzt darauf kam, dass das Mainboard (ein MSI Z97M-G43) da einfach den Lüfter nie unter 50% fallen ließ. Vielleicht ein fehlgeleiteter Abschaltschutz, sicher aber viel zu laut im Idle. Den Radiatorlüfter (mein System hat eine AIO) an Systemfan zu hängen und den Gehäuselüfter als CPU-Lüfter laufen zu lassen war ein Teil der Lösung meines Geräuschproblems, den Rest erledigt die Lüftersteuerung durch das neue Programm.
Installation
Als recht junges Projekt ist fan2go leider noch nicht in vielen Quellen. Um es zu installieren könnte man es wie in der Readme vorgeschlagen von Github herunterladen und in den $PATH verschieben:
curl -L -o fan2go https://github.com/markusressel/fan2go/releases/latest/download/fan2go-linux-amd64 chmod +x fan2go sudo cp ./fan2go /usr/local/bin/fan2go # besser als direkt nach /usr/bin/ fan2go -h
Ohne Konfigurationsdatei erscheint nun erstmal eine Fehlermeldung im Terminal, aber immerhin.
Konfiguration
Die Konfiguration ist leider wieder etwas Handarbeit. Man muss wissen, welche Lüfter man steuern will, sie finden und ihnen Temperaturbereiche zuweisen. Immerhin hilft das Programm hier mit einer Übersicht:
onli@fallout:~$ fan2go detect
> coretemp-isa-0
Sensors Index Label Value
1 Package id 0 (temp1_input) 43000
2 Core 0 (temp2_input) 41000
3 Core 1 (temp3_input) 43000
4 Core 2 (temp4_input) 40000
5 Core 3 (temp5_input) 43000
> amdgpu-pci-0100
Fans Index Label RPM PWM Auto
1 hwmon0 165 18 false
Sensors Index Label Value
1 edge (temp1_input) 43000
> nct6792-isa-0
Fans Index Label RPM PWM Auto
1 hwmon3 0 127 true
2 hwmon3 534 59 false
3 hwmon3 408 64 false
4 hwmon3 1515 255 true
5 hwmon3 0 127 true
Sensors Index Label Value
1 SYSTIN (temp1_input) 39000
2 CPUTIN (temp2_input) 127500
3 AUXTIN0 (temp3_input) 38000
4 AUXTIN1 (temp4_input) 70000
5 AUXTIN2 (temp5_input) 127000
6 AUXTIN3 (temp6_input) -60000
7 PECI Agent 0 (temp7_input) 41500
8 PCH_CHIP_CPU_MAX_TEMP (temp8_input) 0
9 PCH_CHIP_TEMP (temp9_input) 0
10 PCH_CPU_TEMP (temp10_input) 0
> acpitz-acpi-0
Sensors Index Label Value
1 hwmon1 (temp1_input) 27800
2 hwmon1 (temp2_input) 29800
In der Ausgabe von fan2go detect konnte ich meine drei steuerbaren Lüfter finden: Die Einträge hwmon3 unter nct6792 verrieten sich mit der RPM-Angabe. Der bei 1515 stehende konnte nur die Pumpe der AIO sein und muss nur optional gesteuert werden. Es blieben Index 2 und 3 für die Lüfter, was in meinem Fall einmal der Lüfter auf dem Radiator und der im Gehäuse hinten sein musste.
Um die genau zu identifizieren musste ich einmal sudo su aufmachen und dann die PWM-Regler unter /sys/ mit Werten füttern, z.B. so:
onli@fallout:~$ sudo su Password: # bash [root@fallout onli]# cat /sys/class/hwmon/hwmon3/pwm2 58 [root@fallout onli]# cat /sys/class/hwmon/hwmon3/pwm2_enable 1
Wenn da stattdessen bei pwm2_enable eine 5 gestanden hätte, müsste noch eine 1 hineingeschrieben werden:
[root@fallout onli]# echo "1" > /sys/class/hwmon/hwmon3/pwm2_enable
Sonst kontrolliert das Mainboard die Lüfter. Genau so lässte sich auch der PWM-Wert erhöhen (0-255), dann dreht ein Lüfter hoch und man kann erkennen welcher welcher ist.
Jetzt mit allen Infos über das System ausgestattet ging es ans Anlegen der Konfiguration. Meine /etc/fan2go/fan2go.yaml sieht so aus:
# A list of fans to control
fans:
- id: casefan
# The type of fan configuration, one of: hwmon | file
hwmon:
# The platform of the controller which is
# connected to this fan (see sensor.platform below)
platform: nct6792
# The index of this fan as displayed by `fan2go detect`
index: 2
# Indicates whether this fan should never stop rotating, regardless of
# how low the curve value is
neverStop: false
# The curve ID that should be used to determine the
# speed of this fan
curve: cpu_curve
- id: radiatorfan
# The type of fan configuration, one of: hwmon | file
hwmon:
# The platform of the controller which is
# connected to this fan (see sensor.platform below)
platform: nct6792
# The index of this fan as displayed by `fan2go detect`
index: 3
# Indicates whether this fan should never stop rotating, regardless of
# how low the curve value is
neverStop: false
# The curve ID that should be used to determine the
# speed of this fan
curve: cpu_curve
- id: pump
# The type of fan configuration, one of: hwmon | file
hwmon:
# The platform of the controller which is
# connected to this fan (see sensor.platform below)
platform: nct6792
# The index of this fan as displayed by `fan2go detect`
index: 4
# Indicates whether this fan should never stop rotating, regardless of
# how low the curve value is
neverStop: true
# The curve ID that should be used to determine the
# speed of this fan
curve: pump_curve
# A list of sensors to monitor
sensors:
# A user defined ID, which is used to reference
# a sensor in a curve configuration (see below)
- id: cpu_package
# The type of sensor configuration, one of: hwmon | file | cmd
hwmon:
# A regex matching a controller platform displayed by `fan2go detect`, f.ex.:
# "coretemp", "it8620", "corsaircpro-*" etc.
platform: coretemp
# The index of this sensor as displayed by `fan2go detect`
index: 1
- id: system_package
# The type of sensor configuration, one of: hwmon | file | cmd
hwmon:
# A regex matching a controller platform displayed by `fan2go detect`, f.ex.:
# "coretemp", "it8620", "corsaircpro-*" etc.
platform: nct6792
# The index of this sensor as displayed by `fan2go detect`
index: 1
curves:
- id: cpu_curve
# The type of the curve, one of: linear | function
linear:
# The sensor ID to use as a temperature input
sensor: cpu_package
# Sensor input value at which the curve is at minimum speed
min: 30
# Sensor input value at which the curve is at maximum speed
max: 80
- id: pump_curve
# The type of the curve, one of: linear | function
linear:
# The sensor ID to use as a temperature input
sensor: cpu_package
# Sensor input value at which the curve is at minimum speed
min: 40
# Sensor input value at which the curve is at maximum speed
max: 80
Sie ist simpel abgeleitet von den Beispielen in der Readme. Man erkennt, wie die Zuordnung zu den Indezes und der Plattform der Lüfter funktioniert und dass jeweils ein Lüfter, ein Sensor und eine Kurve gebraucht wird – wobei natürlich zwei Lüfter sich auch eine Kurve teilen können. Zwischen Minimal- und Maximaltemperatur linear zu schalten ist ein sehr simpler Ansatz, kann auch funktionieren, wenn nicht können auch PWM-Schritte angegegen werden. Da erklärt die Githubseite mehr.
Nicht wundern: Die AIO-Pumpe über den PWM-Wert zu steuern macht man nicht immer, oft kann sie auf 100% laufen. Bei meiner alten Corsair H90 aber piepst sie dann zu arg.
Starten
Nun startet man das Programm einfach mit:
sudo fan2go
Das System sollte man nun ordentlich testen, dass es ja nicht überhitzt. Stimmt alles könnte man wie in der Readme vorgeschlagen einen Systemdienst anlegen, ich packte mir den Befehl stattdessen in die /etc/rc.local.
Ich bin mit dem Ergebnis ganz zufrieden, mein System ist deutlich leiser geworden und bei fancontrol wollte die alte Konfigurationsdatei nicht mehr funktionieren. Eine Alternative zu haben ist toll. Ich vermisse aber ein Interface, das die manuelle Konfiguration ersetzt. Müsste ja nicht gleich komplett grafisch sein, schon eine UI im Terminal würde mir reichen.
Wichtiger aber noch: Es fehlt die Unterscheidung zwischen dem Start-PWM-Wert und dem Stop-PWM-Wert, die ja oft sehr unterschiedlich sind, da ein Lüfter viel mehr Energie zum Losdrehen braucht als zum Weiterdrehen. Deswegen sollte die Option neverStop vermieden werden, sie setzt den Start-PWM-Wert als Minimum fest und ist daher für reguläre Lüfter ziemlich laut. Vielleicht der gleiche Fehler wie der meines Mainboards anfangs. Nur für die Pumpe passte das perfekt. Ich hoffe da entwickelt sich das Projekt noch weiter, sodass man die Option auch für Lüfter setzen kann.
Trotz der Einschränkungen finde ich das Programm schon jetzt ziemlich großartig. Vielleicht ist es auch für den ein oder anderen Leser hilfreich, gerade in dieser Phase des Sommers.
ProtonUp-Qt erleichtert das Protonupdate noch mehr
Monday, 2. May 2022
Mit protonup installiert man im Terminal die neueste Version von Proton-GE, was eine aktuellere und verbesserte Variante von Proton ist. Oft lassen sich so mehr Windowsspiele besser unter Linux spielen. ProtonUp-Qt ist eine GUI für dieses Kommandozeilenprogramm und erleichtert die Bedienung doch erheblich. Zumindest das Entfernen alter Versionen ist damit einfacher. So sieht es aus:
Nett auch, dass damit trotz des Namens nicht nur Proton aktualisiert werden kann. Sondern es kann auch Luxtorpeda, Boxtron und Roberta installieren. Das sind jeweils Helferprogramme, die sich ähnlich wie Proton in Steam vor die Spiele schalten und sie dann durch Auswechseln der Engine (Luxtropeda, Roberta) bzw des Emulators (Boxtron) verbessern.
Da ProtonUp-Qt als AppImage von der Webseite heruntergeladen kann läuft es problemlos auf jeder Linuxdistribution, Nutzer müssen es nicht selbst kompilieren oder warten bis es in die Quellen kommt.
Linksammlung 17/2022
Friday, 29. April 2022
Solo V2, Vorstellung und Einrichtung unter Linux (Void)
Monday, 11. April 2022
Wie auf Zuruf kam hier vorhin der Solo V2 an. Das ist ein USB-Gerät, das als zweiter Faktor zum Passwort dienen kann. Statt also zusätzlich zur Passwortabfrage eine SMS oder eine Email zu bekommen oder einen Code in einer App wie FreeOTP+ zu generieren wird der USB-Stick eingesteckt und aktiviert.
Das ganze war ein Kickstarterprojekt, der Nachfolger zum ersten Open-Source-Stick von SoloKeys. Stichwort ist dabei FIDO2, der Standard nach dem die Abstimmung zwischen Authentifizierungssuchendem und Stick funktioniert.
Das Konzept
Es geht also um den zweiten Faktor beim Einloggen in (im Normalfall) Webseiten. Ein per SMS gesendeter Code ist dafür die simpelste Lösung, hat aber den Nachteil relativ unsicher zu sein. Denn Telefonnummern können ziemlich einfach gestohlen/umgeleitet werden. Zudem braucht man dann immer Telefonempfang, was bei einer Reise auch mal schwierig sein kann.
Da sind die Apps mit ihren synchronisierten Codes (TOTP) besser, denn sie funktionieren offline. Aber auch sie sind nicht ideal: Telefone mit ihren vielen und oft proprietären Apps sind an sich keine sichere Umgebung, außerdem werden sie gern geklaut und können schnell mal kaputtgehen.
Daher wirkt so ein dediziertes Gerät wie der Solo, oder generell Fido-Sticks, wie eine gute Lösung für einen Zweitfaktor. Die Software darauf ist minimal und dient nur dem Zweck der Codegenerierung bzw Keyverwaltung. So ein USB-Stick ist relativ uninteressant zu stehlen und er hat schlicht kein Display was kaputtgehen kann, kann sogar vor Wasser geschützt werden. Zudem ist er einfach zu benutzen: Einfach einstecken, Knopf drücken (oder in diesem Fall: die Seiten berühren) und fertig. Mit FIDO2 samt WebAuthn gibt es auch bereits fertige Standards, die Seiten unterstützen. Und theoretisch kann das ganze auch statt dem Passwort genutzt werden, also als passwortloser Login (und damit als Haupt- statt Zweitfaktor), wobei dann unempfehlenswerterweise die Sicherheit alleine am Besitz des Sticks hängen würde.
Aber was, wenn solch ein Stick verloren oder doch kaputt geht? Das muss kein Problem sein. Webseiten, die solche USB-Sticks unterstützen, sollten immer mehr als einen zweiten Faktor unterstützen. Der zusätzliche kann dann einfach ein zweites Gerät sein, das an einem sicheren Ort aufbewahrt wird. Oder es ist dann eben doch die Telefonapp, die das Backup stellt, wiederum gesichert mit einem Offsitebackup der Appdaten.
Das Gerät
Der Solo V2 sieht nett gemacht aus. Direkt nach dem Auspacken:
Die Zeichnung ist hübsch und die Hardware selbst hat was. Mit der Hülle drumrum sieht man davon zwar nicht mehr viel. Aber dafür bleiben mit ihr nur noch die goldenen Kanten zu sehen, was auch ziemlich gut wirkt.
Ich hatte erst gar nicht verstanden, wie er zu benutzen ist und die Dokumentation erklärt das nirgends deutlich. Anfangs führte mich die runde Ausbuchtung in der Mitte in die Irre, als ob das ein Knopf sein sollte. Aber das ist wohl nur ein Überbleibsel vom Vorgänger. Tatsächlich muss man am PC die goldenen Kanten berühren, damit der Stick seine Arbeit tut.
Highlight dieser USB-A-Version ist das einfache Einstecken. Denn die Seite ist egal, der Stick funktioniert egal wieherum er im USB-Port sitzt. Das beseitigt einen massiven Nervfaktor für so ein Gerät, das ja im Zweifel relativ häufig eingesetzt werden muss und je nach Umgebung auch nicht immer einfach eingestöpselt bleiben kann. USB-C hätte den gleichen Vorteil gehabt, aber am PC hat man nunmal meist mehr USB-A-Anschlüsse, für das Telefon hätte ich den Solo nicht gebraucht.
NFC kann der V2 auch, aber mir ist nicht klar welchen Zweck das hat. Ermöglicht das Einloggen in Webseiten/Apps am Telefon geschützt mit einem Zweitfaktor, ohne den Stick anstecken zu müssen? Es stört mich durchaus, dass ich diese Information nirgends klar beschrieben finde.
Es gibt aber einen klaren Schnitzer: Die grüne LED ist viel zu hell.
Sie blendet trotz der Hülle so sehr, dass ich sie abkleben werde. Schade, dass das nötig ist.
Einrichtung unter Linux
Als ich den Fido-Stick dann bei mir testen wollte funktionierte er erst nicht. Die Packung verweist auf diese Startanleitung, derzufolge er durchaus direkt funktionieren könnte. Aber nicht unbedingt unter Linux. Da gebe es manchmal udev-Probleme, sagt die FAQ. Aber tatsächlich hilft die verlinkte udev-Regeldatei da nicht. Ich vermute, weil der Solo V2 in ihr andere IDs bräuchte.
Da kam ich erstmal nicht weiter, die Datei mit den mir von lsusb angezeigten IDs anzupassen griff nicht. u2f-hidraw-policy zu installieren war dann für mich unter Void die Lösung:
sudo xbps-install u2f-hidraw-policy
Das Paket fügt den System eine udev-Regel hinzu, die mithilfe eines kleinen Helferprogramms alle Fido-Sticks dem Nutzer und damit dem Browser zugänglich macht. Einmal aktivieren:
sudo udevadm control --reload-rules && sudo udevadm trigger
Jetzt sollte es gehen.
Einsatz zur Accountabsicherung
Nach der Einrichtung kann man den Solo V2 als Zweitfaktor einem Account hinzufügen. Ich machte das direkt bei meinem Googleaccount, der trotz meiner stark reduzierten Googlenutzung noch ein Sicherheitsrisiko ist. In den Sicherheitseinstellungen gibt es eine Option für die 2-Faktor-Authentifizierung. Dort kann ein USB-Gerät hinzugefügt werden, ein Security Key:
Und nachdem ich dann darauf kam, dass auf die goldenen Seiten gedrückt werden muss, funktionierte das auch. Jetzt ist der Fidostick ein weiterer Zusatzfaktor, der beim Einloggen statt den anderen Möglichkeiten – wie der Bestätigung im eingeloggten Telefon – genutzt werden kann.
Fazit
Es muss sich noch zeigen, wieviel ich den Solo V2 in der Praxis nutzen werden. Gekauft habe ich ihn um die Option zu haben, statt SMS und Telefonsoftware einen noch sichereren zweiten Faktor einsetzen zu können. Und auch wenn Google da mein erster Testkandidat war geht es mir mehr um Dienste wie Github. Wobei ich auch die Hoffnung habe, dass Banken durch Regulierungen von ihren proprietären Schrottapps wegkommen und dann eher Fido-Sticks als Alternativlösungen unterstützen.
Vor allem aber fand ich es sehr sympathisch, dass SoloKeys in diesem Bereich auf eine FOSS-Lösung setzt. Ihr Firmware-Framework Trussed ist nicht nur auf Github, sondern steht auch unter einer freien Lizenz. Noch dazu ist es in Rust geschrieben, was die richtige Wahl für solch sicherheitskritische Software ist. Das ist eine Seltenheit bei diesen Sicherheitslösungen, bei denen oft große Firmen mit möglichst intransparenten und teuren proprietären Lösungen mit möglichsten vielen ®, ™ und Patenten andere große Firmen adressieren.
Kann man einen Solo V2 gerade kaufen? Ich glaube nein. Für mich sieht es nur so aus, als könnte er immer noch auf Indiegogo vorbestellt werden. Der Vorgänger wird in ihrem Webshop verkauft, ich würde vermuten dass der V2 da irgendwann dazukommt.
FreeSync-Range unter Linux anpassen
Monday, 29. November 2021
Unter Windows lassen sich relativ einfach die FreeSync-Grenzwerte von Monitoren anpassen. Unter Linux geht das auch, aber es ist weniger einfach – und bei mir war es auch nicht erfolgreich. Trotzdem hier der Zusammenschrieb, für einen erneuten Versuch in der Zukunft.
Im Grunde kann man in großen Teilen dieser Anleitung folgen (die ich leider erst jetzt fand), aber ich musste zusätzlich mit dracut arbeiten um die neue Konfiguration beim Booten laden zu können.
Wie man FreeSync überhaupt aktiviert habe ich in einem früheren Artikel schonmal beschrieben.
Die Anpassung sollte harmlos sein, aber garantieren kann das niemand. Und selbst wenn sie nur nicht erfolgreich ist, kann nach den folgenden Änderungen der Monitor unter X auch ganz ausbleiben, sodass dann die Konfiguration in der Konsole zurückgestellt werden oder der Monitor solange an einen anderen Grafikkartenanschluss muss. Man sei sich dem bewusst.
EDID auslesen
Die EDID ist eine Datei mit den Metadaten des Monitors. In ihr steht auch die FreeSync-Konfiguration. Sie wird beim Starten des Grafiktreibers geladen. Normalerweise läuft das automatisch, aber wir können sie abfangen.
xbps-install read-edid sudo modprobe i2c-dev sudo get-edid > edid.bin
xbps-install ist der Paketmanager unter void, unter Ubuntu ersetzt man das mit apt install.
EDID anpassen
Die soeben erstellte edid.bin kann wxedid nun editieren. Bei mir war das Programm nicht in den Quellen. Daher musste ich manuell ein Release von SourceForge herunterladen, entpacken und kompilieren:
./configure make ./wxedid
Mit dem Programm lässt sich jetzt die edid.bin öffnen. Der für uns interessante Reiter ist "MRL: Monitor Range Limits". Der Eintrag min_vFreq ist die Untergrenze, max_vFreq die Obergrenze. Die jetzt editieren, danach die Datei neu exportieren.
Verschiebe diese neue Datei nun nach /lib/firmware/edid/new_edid.bin
Nur NVIDIA: xorg.conf anpassen
Die EDID lässt sich bei NVIDIA-Treibern per xorg.conf laden, wie das Arch-Wiki beschreibt. Falls noch nicht vorhanden, erstelle dir einen Screen-Konfigurationsblock, z.B. unter /usr/share/X11/xorg.conf.d/20-screen.conf:
Section "Screen"
Identifier "Screen0"
Device "nvidia" # könnte auch anders heißen
Option "CustomEDID" "$MONITOR:/lib/firmware/edid/new_edid.bin"
EndSection
$MONITOR muss noch mit der richtigen ID des Monitors ersetzt werden. Die findet sich per xrandr, war bei mir wie oben zu sehen also DisplayPort-1.
Das sollte es für NVIDIA-Nutzer auch schon gewesen sein. Da ich eine Grafikkarte von AMD benutze konnte ich das aber nicht richtig testen.
Der amdgpu-Treiber kennt CustomEDID aber nicht, deshalb da der folgende Ansatz.
Nur AMD: Die initramfs ergänzen
Es kann sein, dass es bei deinem System für diesen Schritt ausreichte die Datei nach /lib/firmware/edid/ zu verschieben.
Bei mir reichte das nicht, wohl weil die initramfs die EDID laden würde, sie aber auf diesen Ordner keinen Zugriff hat. Ich bekam dann später nach Setzen des Bootparameters diese Fehlermeldung:
*ERROR* Requesting EDID firmware new_edid.bin failed (err=-2)
Mit dracut ändert man das so:
sudo dracut -i /lib/firmware /lib/firmware --force
Der Befehl bläst die initramfs leider sehr auf und man müsste das regelmäßig machen, wenn ich herausfinde wie man das richtig konfiguriert und zielgerichtet nur die EDID-Datei hinzufügt wird dieser Artikel editiert. Aber zum Testen reicht es.
Allerdings benutzt nicht jede Distribution dracut. Dieser Launchpadbug beschreibt eine Lösung für Ubuntus initramfs-tools, was die meisten anderen Distributionen abdecken dürfte.
Nur AMD: Den Bootparameter setzen
Um die EDID dann auch wirklich zu laden setzt man in der /etc/default/grub den Parameter drm.edid_firmware:
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=4 … drm.edid_firmware=DP-2:edid/new_edid.bin"
DP-2 ist systemabhängig und folgt nicht der gleichen Nummerierung wie xrandr. Die richtige findet man mit
grep . /sys/class/drm/card-/status
Nicht vergessen die neue grub-Konfiguration auch anzuwenden:
sudo update-grub
Testen
Beim nächsten Neustart sollte der Treiber den Monitor nun gemäß der neuen EDID ansprechen. Zum Testen empfehle ich wieder VRRTest.
Für meinen Acer CB242Y hat die ganze Aktion nichts gebracht. Erhöhe ich die obere Grenze, wird alle paar Sekunden der Bildschirm schwarz. Senke ich die untere Grenze, wird der Bildschirm schwarz sobald die FPS unter 48 fallen.
Ich fand ein paar Kommentare von Nutzern, bei denen diese Freesync-Anpassung unter Windows ging, aber unter Linux nicht. Es kann durchaus sein, dass die anderen Treiber da mehr herausholen können, oder dass die unter Windows benutzte Software wie CRU beim Editieren der EDID noch weitere Tricks draufhat. Vielleicht geht da also später noch was, vielleicht wird es irgendwann auch komfortabler und der Treiber kann die Freesync-Range ohne den Umweg über die EDID anpassen.
Outland
Wednesday, 29. September 2021
Outland ist ein nativ unter Linux laufendes Spiel, das ich mehr als Plattformer denn als Metroidvania einordnen würde.
Ihr kontrolliert eine Spielfigur, die im Laufe des kurzen Spiels immer mehr kann. Primär Springen und Angreifen, aber vor allem auch die Farbe wechseln kommt sehr schnell dazu. Ob rot oder blau gewählt ist macht dann blaue oder rote Gegner verwundbar, während die herumfliegenden Energiekugeln nur in der Gegenfarbe gefährlich sind.
So immer mehr zu können und die Spielwelt frei zu durchlaufen, wobei mit den neuen Fähigkeiten neue Gebiete freizuschalten werden, das würde zu einem Metroidvania passen. Aber in Outland wird die richtige Route immer vorgegeben. Das Spiel ist also komplett linear, selbst wenn diese Route mal wieder in vorherige Gebiete zurückführt. Wobei es sich regelmäßig lohnt, die Ecken der Karte abseits der Hauptroute abzusuchen um Upgradeschreine zu finden sowie Gold für diese einzusammeln.
Die Geschichte um mörderische Götterschwestern aus Licht und Schatten (rot und blau?) ist belanglos, sie ist klar nur dazu da die Levels etwas zu verbinden. Dafür sieht das farbenfrohe Design wirklich gut aus. Mit den Farbwechseln, den Gegnern und den vielen Energiekugeln wird Outland später schon herausfordernd, aber es fordert nur an ganz wenigen Stellen annähernd die Konzentration eines Bosskampfes bei Hollow Knight, auch die Sprungpassagen sind kürzer und einfacher. Dazu hat Sterben aufgrund der häufigen Checkpoints praktisch keine Konsequenzen.
Wer diese Art von Spielen gerne spielt kann auch Outland spielen und bekommt damit einen kurzen Lückenfüller, der die Spielzeit über durchaus Spaß macht. Denn das Leveldesign ist gelungen, es bietet immer wieder neue Herausforderungen zum Knobeln. Aber der große Wurf ist es leider nicht geworden, trotz des wirklich netten Designs. Dafür fehlt an spielerischer Tiefe und insgesamt an Atmosphäre.
Mit protonup leichter das neueste Proton-GE installieren
Wednesday, 18. August 2021
Der kleine Helfer protonup installiert auf dem System komfortabel die neueste Version von Proton-GE (GloriousEggroll). Das ist eine alternative, schneller mit Updates versorgte Variante von Proton, die von einem Redhat-Entwickler gepflegt wird. Der Vorteil: Damit laufen schlicht mehr Spiele besser. Und die Installation ist mit protonup jetzt noch einfacher (via).
Falls pip3 nicht installiert ist erst das, danach damit protonup installieren:
pip3 install protonup-ng
Update 01.05.2022: protonup kommt bisher mit dem neuen Releasenamen von Proton-GE nicht zurecht. Stattdessen kann man protonup-ng benutzen. Ich habe deswegen die Installationsanleitung oben umgestellt. Die Benutzung unten bleibt gleich.
Kurz einrichten:
protonup -d "~/.steam/root/compatibilitytools.d/"
Und schon kann die neueste Version installiert werden:
onli@fallout:~$ protonup Ready to download Proton-6.14-GE-2 Size : 412.57 MiB Published : 2021-08-02 Continue? (Y/N): Y Downloaded 100.0% - 412.62 MiB/412.57 MiB [INFO] Installed in: .steam/root/compatibilitytools.d/Proton-6.14-GE-2
Außerdem lassen sich alte Proton-GE-Installationen auflisten und entfernen:
onli@fallout:~$ protonup -l Proton-6.1-GE-2 - 1205.08 MiB Proton-4.21-GE-1 - 962.43 MiB Proton-4.21-GE-2 - 962.5 MiB Proton-6.14-GE-2 - 1521.37 MiB Proton-5.9-GE-6-ST - 1202.5 MiB Proton-5.2-GE-1 - 1597.76 MiB Proton-5.9-GE-8-ST - 1212.55 MiB Proton-5.9-GE-5-ST - 1201.3 MiB Proton-5.8-GE-2-MF - 1222.74 MiB Proton-5.21-GE-1 - 1171.04 MiB onli@fallout:~$ protonup -r Proton-4.21-GE-1 Proton-Proton-4.21-GE-1 not installed onli@fallout:~$ protonup -r 4.21-GE-1 Are you sure? (Y/N) Y
Das ist netter als ich glaubte, denn ich hatte keine Ahnung, dass die Installationen so verdammt groß sind.
Nach einem Steam-Neustart kann dann wie gehabt in den Einstellungen generell die neue Protonversion als Standard gesetzt oder sie nur für bestimmte Spiele aktiviert werden.
Nette kleine Erleichterung, fand ich.
Warum bei Anonymität, Privatsphäre und Sicherheit im Netz keine Kompromisse möglich sind
Wednesday, 11. August 2021
Es ist nicht überzogen zu sagen: Die gesellschaftliche Auseinandersetzung um Anonymität, Privatsphäre und IT-Sicherheit entzündet sich gerade zu einen echten Kampf. FOSS-Software spielt in diesem eine Sonderrolle, weil sie unheimlich schwer zu regulieren ist und so Fakten schafft. Dagegen und gegen Anonymität versprechende Firmen gehen Staaten und bestimmte andere Firmen aber verstärkt vor.
Doch kann es hier nicht einfach einen Kompromiss geben? Gibt es sinnvolle Regelungen, die nur da partiell Anonymität entfernen und in die Privatsphäre hineingreifen wo es wirklich sinnvoll ist? Nein, das ist völlig unmöglich und wäre bei umfassender Anwendung das endgültige Ende von Anonymität im Internet, eine nie dagewesene Reduzierung der Privatsphäre und eine gesamtgesellschaftliche Schwächung der IT-Sicherheit.
Zum Kontext: Dies ist eine Entgegnung auf einen Kommentar von Gerrit bei curius.de, der wiederum war wohl eine Reaktion auf meinen Kommentar zu seinem Blogartikel über die Datenweitergabe von ProtonMail an US-Behörden. Ich ziehe mir meine Position nicht völlig in der Kürze der Zeit aus dem Allerwertesten; Anonymität – wenn auch nicht in diesem Kontext – war Thema meiner Doktorarbeit. Außerdem arbeite ich momentan im Randbereich privatsphärenwahrender Kommunikation.
Die derzeitige gesellschaftliche und technologische Ausnahmesituation
Machen wir uns erst einmal kurz klar wo wir stehen: Am wahrscheinlichen Endpunkt einer historisch einmaligen Ausnahmesituation. Dem Staat gegenüber anonyme Kommunikationsmittel hat es praktisch nie gegeben. Wo kommuniziert wird, wird potentiell mitgehört und kontrolliert – das haben sich Staaten immer herausgenommen. Und doch haben wir sie derzeit.
Gerade der deutsche Zensor war eine historische Konstante, der nicht nur prüfte was die Bevölkerung untereinander sich schrieb und sagte, sondern auch was veröffentlicht werden durfte. Bekanntes Beispiel ist der Einfluss des Zensors auf die deutschen Aufklärer im 18. Jahrhundert. Geistig verwandte Fortführung davon ist die Zensur von Videospielen via einem Index, nichts anderes als einer Zensurliste ungewollter Kunst, oder die Impressumspflicht, die der Minimierung anonymer Publikationen dient. Gerade Deutschland hat also eine tradierte und aktive Zensur- und Kontrollpraxis. Das Land ist aber beim Zugriffnehmen auf Kommunikationsmedien nicht einmalig.
In Telekommunikationsinfrastruktur muss der Staat mithören dürfen, sagt dieser. Telefonleitungen beispielsweise wurden einfach angezapft. Bei Internettechnologie wurden solche Vorschriften früh übernommen. So gibt es verpflichtend Abhörschnittstellen bei jedem Email-Provider ab einer gewissen Kundenanzahl, mit denen dann das gesamte Emailpostfach heimlich mitgelesen werden kann. Auch andere Staaten sind da extrem, die USA beispielsweise verbot kurzerhand den Export von brauchbarer Verschlüsselung und versucht immer wieder, die Anwendung ganz zu verbieten.
Dieser absolute Überwachungsanspruch zusammengenommen mit den technischen Gegenmaßnahmen und Überwachungsmöglichkeiten schafft eine interessante Situation, die sowohl in die Richtung von unerreichten Freiheitsrechten als auch unbekannt totaler Überwachung ausschlagen kann:
- Unsere Kommunikation und unsere Alltagstätigkeit erfolgt mehr als jemals auf potentiell komplett abhörbaren Netzwerktechnologien.
- Gleichzeitig haben wir aber Verschlüsselungsmethoden gefunden, die den Nutzern dieser Dienste vollständige Schutz vor dem Mitlesen ihrer Kommunikationsinhalte gewähren könnten.
- Allerdings hat der Staat jetzt erstmals die Möglichkeit, unverschlüsselte oder Kommunikation mit geknackter Verschlüsselung vollständig aufzuzeichnen und auszuwerten.
Man kennt vielleicht dieses Bild der sich wiederholenden Geschichte. Und die Entgegnung, dass sich nichts wiederholt, es reime sich nur. Das passiert hier: Im Grunde laufen die gleichen Entwicklungen wie bei jedem Kommunikationsmedium – anfängliche Anonymität und Datensicherheit durch Ignoranz, dann bekommt der Staat Angst um seine Macht, dann wird mitgelesen. Hier aber ist die Dimension neu, mit der zum einen dagegen vorgegangen werden kann und wie vollständig zum anderen das Abhören durchgeführt würde. Und außerdem ist enorm anders, wie weit in den privatesten Lebensbereich die Technologienutzung und damit das Abhören hineinreicht. Es ist eine Weiterentwicklung der damaligen Situationen.
Sicherheit geht nicht stückchenweise
In dieser historisch einmaligen Situation rennen wir also in die Frage: Wieviel Anonymität und Privatsphäre wollen wir zulassen? Und damit in zwei Probleme: Der alte Kompromiss der staatlichen Legitimierung des Eingriffs war niemals gut und ist es heute noch weniger, zweitens ist die technische Konsequenz dieser Eingriffsermöglichung enorm.
Nehmen wir einen Chatanbieter, der bis jetzt vollständig anonymisierte und Ende-zu-Ende-verschlüsselte Kommunikation ermöglicht hat. Logdateien gibt es nicht. Die Entschlüsselung bräuchte für jede einzelne Nachricht jeweils das jahrelange Arbeiten von Supercomputern. Selbst Metadaten darüber wer wem schreibt wird mittels Datendurchmischung unerhebbar gemacht. In Sachen Datenschutz und Anonymität die perfekte Lösung – und nah dem, was Dienste wie Signal heute tatsächlich anbieten.
Wenn wir dem Staat hier einen Eingriff auch nur auf Einzelne erlauben, wird die Anonymität und der Datenschutz aller reduziert. Denn der ginge jetzt hin und sagte: Logdateien müsst ihr führen. Ergo ist der Dienst nicht mehr anonym, ein entsprechend mächtiger Angreifer kann die IP-Daten zuordnen. Dann sagt er: Mitlesen will ich auch. Also ist die gesicherte Privatheit der Kommunikation weg, weil die Ende-zu-Ende-Verschlüsselung abgeschafft wird.
Das ist keine Theorie: Genau das ist bei der Kommunikationslösung für Rechtssachen(!) passiert, da weder das Anwaltspostfach noch De-Mail eine direkt aktive integrierte Ende-zu-Ende-Verschlüsselung haben. Wenn staatliche Lösungen das schon bei so absolut kritischen Daten machen, dann sieht man wo das Ziel liegt. Und tatsächlich fordert "der Staat" derzeit die Abschaffung von Ende-zu-Ende-Verschlüsselung bei Chatdiensten und will das per Gesetz durchdrücken.
Der Angreifer ist mächtiger als je zuvor
Schlimmer: Es ist nicht so, dass diese Daten dann nur per Richterentscheidung in kritischsten Situationen erhoben werden. Sondern da sie nun als gewollte Schwachstelle in die Kommunikationssysteme eingebaut sind, stehen sie auch anderen Angreifern zur Verfügung. Das kann die Hackerbande aus Nordkorea sein, die sich Zugriff auf die nun erhobenen Logdateien verschafft. Oder, garantiert ist der Zugriff der Geheimdienste.
Das ist keine Verschwörungstheorie. Oder anders: Es war mal eine, aber sie hat sich als wahr herausgestellt. Dass die Geheimdienste eine umfassende Datenabhöraktion am Laufen haben war der Kern der Enthüllungen von Snowden. Die NSA will den gesamten Internetverkehr durchleuchten und soweit möglich speichern. Geheimdienste wie der BND helfen dabei, indem sie den Internetverkehr auf den sie Zugriff haben an diesen fremden Geheimdienst weiterleiten. So umgehen sie, dass sie keine Dauerüberwachung der eigenen Bürger durchführen dürfen – machen sie auch nicht, sie leiten nur die Rohdaten weiter und bekommen im Gegenzug Auswertungsergebnisse.
Ich halte das für Landesverrat – obwohl das bekannte Ausmaß der BND-Involvierung vergleichsweise gering ist. Doch selbst wenn die Einschätzung stimmen würde, Konsequenzen gab es ja nichtmal als bekannt wurde, dass Merkels Telefon abgehört wird. Welchen staatlichen Schutz können sich normale Bürger da erhoffen?
Und nebenbei: Ja, das geheimdienstliche Datensammeln ist mehr als das Mitlesen von Texten. Es schließt den Zugriff auf Audio- und Videodaten ein, inklusive der Fähigkeit, heimlich Kameras von Laptops und Smartphones aktivieren zu können. Das mag in einem kleineren Maßstab passieren, ist aber grundsätzlich auch eine Fähigkeit, über die Geheimdienste wie Strafverfolgungsbehörden verfügen wollen.
Aber nochmal: Es geht nicht alleine um Geheimdienste. Wer das für Aluhutzeug hält kann sich dieses Argument wegdenken. Auch ohne sie ist das Wirken des Gesetzgebers und der normalen Behörden zerstörerisch für die digitale Privatsphäre. Das Vorschreiben von Überwachungsmöglichkeit bedingt Systeme, die überwachbar sind – so trivial kann man es sehen. Überwachbare Systeme aber sind angreifbar, nicht nur von dem, der die Überwachbarkeit in Auftrag gegeben hat. Außerdem ist es völlig berechtigt, auch bei den derzeit nach Überwachungsmöglichkeiten schreienden Staatsgewalten ein enorm hohes Missbrauchspotential zu sehen. Und sei es nur durch Missbrauch einzelner - man denke an die Adressen von Zielpersonen, die wohl über Polizeicomputer an Naziterroristen weitergegeben wurden.
Das ist die Welt, in dem wir uns bewegen. Und in dieser kann es nur absolute oder keine Softwaresicherheit geben. Das diktiert die Technik, aber es diktiert auch das Angreifermodell. Da der Angreifer staatliche Stellen sind und damit fast allmächtig, ist die einzige Chance auf anonyme und private Kommunikation in den globalen Kommunikationssystemen das Erstellen von Kommunikationswegen, die vollständig von jedwedem Fremdzugriff geschützt sind und bei denen keine verwertbaren Metadaten anfallen. Auf Endgeräten, die von Hardware- bis Softwareebene vollständig sicher sind, sonst werden die angegriffen.
Von diesem Idealzustand sind wir weit entfernt, gerade die Software und die Hardwareseite ist ein Thema für sich – Apple zeigte gerade wieder, dass proprietäre Systeme die eigenen Nutzer ausspionieren und an Strafverfolgungsbehörden verraten. Wir können aber hoffen, dass der Zugriff über diese Ebenen noch nicht vollständig ist.
Mit den Grenzen könnten wir leben
Kommen wir zum Begriff des rechtsfreien Raums. Der sei die Folge, wenn der Staat keine Vollkontrolle hat. Das stimmt nicht, denn es ist ein maßlos überzogenes Konzept und pure Propaganda von Verfechtern staatlicher Überwachung.
Es geht nicht um Rechtsfreiheit. Es geht um Grenzen der Rechtsdurchsetzung. Diese Grenzen gibt es auch heute schon außerhalb des Netzes und wir glauben trotzdem nicht, dass in Deutschland keine Rechte mehr gelten würden.
Was wir machen, ist abzuwägen: Es gibt Gesetze, die in einem gewissen Maße akzeptiert werden. Andere Regeln sind veraltet, offensichtlich Grundrechtswidrig und gehören abgeschafft, wie damals die erlaubte Vergewaltigung in der Ehe oder heute (natürlich weniger schlimm) das fundamentalchristliche Tanzverbot. Aber wir haben auch heute natürlich ernste Missstände, wie das Verbot der Aufklärung über Abtreibungen. Die Gesellschaft in einem diffusen Prozess entscheidet dann, welche Regeln wie hart durchgesetzt werden, welche außer Kraft fallen schon bevor sie offiziell abgeschafft werden. Und schaut dabei auf die Verhältnismäßigkeit: Der Staat wirft keine Bombe auf einen kompletten Frankfurter Stadtteil, wenn Karfreitag dort jemand Musik abspielt. Selbst wenn die Musik ansonsten nicht abschaltbar ist.
Den Komplettanspruch der vollständigen Regeldurchsetzung mit allen Mitteln gibt es, aber er ist hoch autoritär und keine Mehrheitsmeinung. Und führt nicht zu einen Staat, in dem Menschen freiwillig leben würden.
Genau diesen Abwägeprozess gilt es auch im vermeintlich rechtsfreien Raum des Internets zu durchlaufen. Nationale Gesetze mögen in Einzelfällen gelten, aber wie und wie weit sie durchgesetzt werden können hat Grenzen. Es kann nicht weltweit jedwede Anonymität abgeschafft werden, nur weil ein Mensch einmal einem anderen eine Morddrohung geschickt hat. Oder: Ja, wir könnten das tun, aber es wäre völlig unverhältnismäßig.
Doch es gibt keinen Mittelweg, keinen Kompromiss, der die Grundrechtsaufhebung nur temporär für einige wenige erlauben würde, denn der Mechanismus dafür ist angesichts der übermächtigen Angreifer und der notwendigen Schwächung der Grundsicherheit verbaut. Wir sehen das bei den alten Kommunikationsmedien wie dem Telefonnetz: Die Protokolle dahinter sind komplett unsicher. Das ist der Grund, warum SMS keine besonders sichere Wahl bei einer Zwei-Faktor-Authentifizerung ist. Aber die Unsicherheit der Netze wurde – so die These – bewusst in Kauf genommen um Abhörbarkeit herzustellen. Auf jeden Fall wurde sie Jahrzehntelang nicht problematisiert. Es ging ja auch meist um nationale Netze, mit wenigen ausländischen Angreifern.
Die aber gibt es im globalen Internet. Gleichzeitig kommen wir da zu dem Problem, dass ganz verschiedene Staaten Daten von Firmen anfordern. Der eine mag dem demokratischen Deutschland noch vertrauen. Der in den Faschismus rutschenden USA dann schon weniger. Und dem genoziden China schon gar nicht. Aber die alle fordern verfügbare Daten an, zunehmend selbst bisher nicht verfügbare.
Die durchaus vernünftige Alternative ist, eine begrenzt mögliche Rechtsdurchsetzungsfähigkeit einfach hinzunehmen. Ja, dann kann der Staat eben nicht die IP des Senders einer unschönen Nachricht herausfinden. Aber wenn der Empfänger die Nachricht zur Anzeige bringt kann die Strafverfolgsbehörde den Text analysieren und findet den Sender vielleicht so. Oder es gibt es einen Informant im Umfeld des Täters. Sogar bei Naziterroristen hätte das funktioniert, wenn da sorgfältig gearbeitet worden wäre. Nur weil das Extreminstrument der vollständigen Internetüberwachung nicht verfügbar ist heißt das ja nicht, dass es gar kein Instrument für Strafverfolgungsbehörden gäbe.
Deswegen kann es hier keinen Kompromiss geben. Erstens, weil dann Kommunikationsdienste generell nicht mehr anonym und privat wären (insofern sie das heute sind). Zweitens, weil wir über die Vertraulichkeitseigenschaften von technischen Systemen reden, die bedroht werden durch skrupellose Angreifer mit den Fähigkeiten von Staaten, mit technischen fähigen Auswertungssystemen. Gegen die ist ein partieller Schutz über Regularien im Sinne einer verstaubten Bonner Behördenstube nicht mehr möglich.
