Beiträge von Spaceloop

Das US-Heimatschutzministerium nutzt ein riesiges Überwachungssystem, um Migranten festzunehmen. Darüber möchte die Behörde die Öffentlichkeit im Dunkeln lassen.

https://www.zeit.de/politik/ausland/2026-09/the-deportation-project-ice-ueberwachungssystem-migration-usa

Wie auch immer man zum Migrationsthema steht, ich finde die Errichtung eines solchen Systems in einem sich selbst als freiheitlich betrachtenden Land ziemlich entsetzlich. Man hat in den USA im Prinzip genau die Dystopie hochgezogen, vor der seit den 1970ern immer gewarnt wurde. In Deutschland führte dies zu Entwicklungen wie dem Datenschutzrecht, mit dem Hessischen Datenschutzgesetz als Vorreiter, und dem Volkszählungsurteil von 1983 und der damit begründeten, bis heute weiterentwickelten Rechtsprechung.

Und in den USA machen sie jetzt einfach.

Bei Fortschreiten dieser Entwicklung ist in den USA niemand mehr sicher, denn wie schnell ist so ein System doch auch für andere "Ziele" angepasst...

Fand es jetzt doch etwas umständlich, zwei Window Manager bzw. Desktops parallel zu betreiben.

Aktueller Stand ist ein Ghostty-Termiinal in KDE, welches automatisch den Terminalmultiplexer tmux startet, und rechts yazi startet. Fürs motorische Gedächtnis wird mit STRG+HJKL ein Bereich gewählt und mit ALT+HJKL weiter gesplittet.

~/.config/ghostty/confiig:

# Startet tmux, splittet und sorgt dafür, dass die Session beim Schließen gelöscht wird
command = tmux new-session -d -s frisch \; set-option -t frisch destroy-unattached on \; split-window -h -t frisch "yazi; exec $SHELL" \; attach-session -t frisch

# Sorgt dafür, dass Ghostty nach dem Exit ohne Verzögerung schließt
wait-after-command = false

~/.tmux.conf:

# =====================================================================
# 1. NEUE FENSTER SPLITTEN (Mit ALT)
# =====================================================================

# Alt + h teilt das Fenster HORIZONTAL (Pane oben/unten)
bind -n M-h split-window -v -c "#{pane_current_path}"

# Alt + v teilt das Fenster VERTIKAL (Pane links/rechts)
bind -n M-v split-window -h -c "#{pane_current_path}"


# =====================================================================
# 2. ZWISCHEN FENSTERN WECHSELN (Mit STRG + Vim-Keys)
# =====================================================================

# Strg + h wechselt zum linken Fenster
bind -n C-h select-pane -L

# Strg + l wechselt zum rechten Fenster
bind -n C-l select-pane -R

# Strg + k wechselt zum oberen Fenster
bind -n C-k select-pane -U
# Strg + j wechselt zum unteren Fenster
bind -n C-j select-pane -D


# =====================================================================
# 3. BASIS-INSTELLUNGEN (Für yazi & Ghostty)
# =====================================================================



# Erlaubt yazi und Ghostty die Kommunikation durch tmux hindurch
set -g allow-passthrough on

# Verhindert Verzögerungen bei Tastatureingaben
set -s escape-time 0

# Setzt das richtige Terminal-Profil
set -g default-terminal "tmux-256color"

set-hook -g pane-exited 'select-layout -E'


# Sicherstellen, dass beendete Prozesse das Pane SOFORT schließen
set -g remain-on-exit off

Ich finde das einen netten Kompromiss. Ich habe jetzt ein schön aufgebohrtes Standard-Terminal, auch für normale Administration wie zypper dup etc. Bei yazi kann ich gut hjkl üben. Es respektiert auch verknüpfte Dateitypen und startet z.B. bei MP3s QMMP. Das ganze zusätzlich aufgepumpt mit zsh als Standardshell, ohmyzsh, autojump, powerlevel10k, zsh-autosuggestions und zsh-syntax-highlighting. Für meine Zwecke nun ein maximal getuntes Terminal, ohne auf den Komfort von KDE verzichten zu müssen.

KERNEL=="event[0-9]*", SUBSYSTEM=="input", ATTRS{name}=="Telink Wireless PTP Receiver Touchpad", TAG+="uaccess"

Hatte vergessen, bei Kernel das " zu schließen, und zu attrs muss ein doppeltes =.

Aktuelle config.yml:

swipe:
  3:
    left:
      command: "qdbus6 org.kde.kglobalaccel /component/kwin invokeShortcut 'Walk Through Windows'"
    right:
      command: "qdbus6 org.kde.kglobalaccel /component/kwin invokeShortcut 'Walk Through Windows (Reverse)'"
    up:
      command: "qdbus6 org.kde.kglobalaccel /component/kwin invokeShortcut 'Window Maximize'"
    down:
      command: "qdbus6 org.kde.kglobalaccel /component/kwin invokeShortcut 'Window Minimize'"

threshold:
  swipe: 0.5

interval:
  swipe: 0.8

ganz simpel: hochwischen mit drei Fingern maximiert Fenster (oder geht wieder auf nicht-maximiert), runter minimiert Fenster, rechts und links wischen: durch die Fenster wechseln

Zur Info: ich habe das System mittlerweile wieder auf normale Updates zurück konfiguriert. Auf die Dauer hatten die transaktionalen Updates dann doch zu oft zu viele Ausreden, warum sie nicht durchgelaufen sind. Man hat es unter Tumbleweed dann irgendwann gemerkt, dass der Kernel keine neuen Versionen bekam. Und das trotz No Vendor Change und non interactive usw...

UPDATE:

Die obige Methode mit der Gruppe funktioniert zwar. Allerdings sorgt sie dafür, dass alle Prozesse alle Eingaben lesen und schreiben können. Eigentlich ist es ein Sicherheitsfeature von Wayland, dass hier eine saubere Trennung herrscht. Keyloggern wird somit die Arbeit erschwert.

Sichere Variante für das Perixx:

0) erstmal den User wieder aus der input-Gruppe entfernen.

sudo gpasswd -d $USER input

Nach einem Neustart sollte dann zunächst gar nichts außer einfache Mausfunktion laufen.

1) den Namen ermitteln, mit dem sich das Touchpad im System angemeldet hat:

Liste anzeigen lassen:

cat /proc/bus/input/devices

evtl. nach "Touchpad" suchen:

cat /proc/bus/input/devices|grep "Touchpad"

Ausgabe:

N: Name="Telink Wireless PTP Receiver Touchpad"

Der Name ist also

Telink Wireless PTP Receiver Touchpad

3) Die oben angelegte rules-Datei öffnen bzw. neu anlegen:

sudo nano /etc/udev/rules.d/71-touchpad.rules

dort sollte stehen:

KERNEL=="event[0-9]*, SUBSYSTEM=="input", ATTRS{name}="Telink Wireless PTP Receiver Touchpad", TAG+="uaccess"

(wahrscheinlich kann man das auch kürzer über eine echo-Umleitung lösen...)

und eben anwenden:

sudo udevadm control --reload-rules && sudo udevadm trigger

Wo hab ich das her?

cflg - Overview

Software Engineer . cflg has 62 repositories available. Follow their code on GitHub.

github.com

Er bietet einen kompletten Installer für fusuma an, der auch ein grafisches GUI für die config.yaml enthält.

GitHub - cflg/fusuma_gui: Fusuma Config is a highly polished, native desktop application for Linux that provides a visual interface for managing Fusuma touchpad gestures. No more writing complex YAML by hand—manage your swipes, pinches, multi-document…

Fusuma Config is a highly polished, native desktop application for Linux that provides a visual interface for managing Fusuma touchpad gestures. No more…

github.com

Ich habe das Projekt nicht getestet oder genutzt. Ich habe lediglich aus der https://github.com/cflg/fusuma…ces/diagnostic_service.py den udev-String für die rules-Datei rausgezogen...

OK, ich hatte die Frage ins Forum gestellt. In den letzten Stunden hab ich die Google KI gelöchert. Ich habe es nicht nur geschafft, die Grundfunktionen ans laufen zu bringen. Die KI hat mir auch geholfen, KDE so einzustellen, dass es auch Drei-Finger-Gesten verarbeitet. Der etwas dekadente KDE-Standard sieht für vieles nämlich 4 Finger vor, was das Perixx aber nicht unterstützt.

- Grundsätzlich sind Gesten seitens KDE nur in einer Wayland-Session vorgesehen!

- Das Programm Touche sollte nicht installiert sein.

Das wichtigste scheint unter openSUSE zu sein, den Nutzer in die input-Gruppe aufzunehmen.

sudo usermod -aG input $USER

Nach meiner Erinnerung liefen dann auch schon die meisten Zwei-Finger-Gesten. Trotzdem kam die KI irgendwann noch mit

sudo gpasswd -a $USER input

Hätte KDE 3 Finger-Gesten voreingestellt, würden die vermutlich auch funktionieren, aber man hat sich für 4 Finger entschieden...

Für eine korrekte Installation wurde mir noch eine udev-Datei ans Herz gelegt:

/etc/udev/rules.d/71-touchpad.rules

Inhalt:

ENV{ID_INPUT_TOUCHPAD}=="1", TAG+="uaccess"

anschließend am Prompt:

sudo udevadm control --reload-rules && sudo udevadm trigger

Für die drei-Gesten-Konfiguration wurden mir zwei Methoden vorgeschlagen:

1) Ein zu kompilierendes KDE-Plugin namens InputActions: Hat nicht funktioniert. Der Menüpunkt ist nicht bei den Desktop-Animationen erschienen, und ließ sich dazu nicht überreden. Also wurde es

2) fusuma

Es handelt sich um ein ruby-tool, was leider nicht in den Repos (meinen genutzten Repos) zu sein scheint.

Also muss es über Ruby installiert werden. Die KI hat einen User install empfohlen.

gem install fusuma --user-install

um KDE über Fusuma steuern zu können, muss das Paket qt6-tools aus den Repos installiert werden:

sudo zypper in qt6-tools

Das Verzeichnis für die Konfiguration ist anzulegen:

mkdir -p ~/.config/fusuma

dort ist die Datei

~/.config/fusuma/config.yaml anzulegen.

Meine sieht aktuell so aus:

swipe:
  3:
    left:
      command: "qdbus6 org.kde.kglobalaccel /component/kwin invokeShortcut 'Walk Through Windows'"
    right:
      command: "qdbus6 org.kde.kglobalaccel /component/kwin invokeShortcut 'Walk Through Windows (Reverse)'"
    up:
      command: "qdbus6 org.kde.kglobalaccel /component/kwin invokeShortcut 'Overview'"
    down:
      command: "qdbus6 org.kde.kglobalaccel /component/kwin invokeShortcut 'ExposeAll'"

threshold:
  swipe: 0.5

interval:
  swipe: 0.8

Es ist zu beachten dass qdbus6 offenbar ein SUSE-spezifischer Dialekt ist. überall sonst heißt es nur qdbus.

nach dem Speichern kann man die Konfiguration auf der Kommandozeile testen, indem man fusuma startet

ich musste allerdings vorher noch PATH in der .bashrc anpassen, indem ich der Datei am Ende diese Zeile hinzugefügt habe:

.bashrc

export PATH="$PATH:/home/geeko/.local/share/gem/ruby/4.0.0/gems/fusuma-3.12.0/exe"
# Fusuma Touch gesten

Anschließend im Terminal:

fusuma

während fusuma läuft, sollten die Gesten funktionieren.

Ist alles soweit klar, kann man das Tool dann im KDE Autostart einfügen, um es permanent im Hintergrund am laufen zu haben.

Hallo Forum,

ich habe meinen Desktop etwas neu organisiert und hatte die Idee, das Perixx Peripad 706 als Mausersatz einzusetzen. Ich habe gehofft, durch die unterstützten Gesten schneller am Desktop navigieren zu können. Teilweise klappt das auch. Allerdings werden unter KDE bei mir aktuell nur sehr wenige Gesten, hauptsächlich mit einem Finger, erkannt.

Jetzt habe ich zum Spaß mal libinput debug-events in der Konsole eingegeben und festgestellt, dass das in libinput durchaus Pitch- und Swipe-Events, der der Beginn und das Ende von Gesten registriert werden. Irgendwie passiert in Plasma damit aber nichts.

Plasma behauptet sogar, dass kein Touchpad angeschlossen wäre.

Szstem ist Tumbleweed.

KDE Plasma ist auf 6.7.3

KDE Framework ist auf 6.28.0

Kernel auf 7.1.3-1

Session ist aktuell X11, aber unter Wayland ist das Verhalten gleich.

Bin etwas weiter gekommen.

Ich hatte die Befürchtung, dass man bei der manuellen Konfiguration sich heillos verzettelt. Beim weiteren recherchieren habe ich dann festgestellt, dass es von openSUSE bereits ein eigenes Pattern gibt:

openSUSEWay:

https://en.opensuse.org/Portal:OpenSUSEway

Ich habe dann beschlossen, erst einmal damit einzusteigen, Tumbleweed mit diesem Pattern zu installieren und es dann für meine Bedürfnisse anzupassen. D.h. mit kitty (Terminal) statt alacritty, zsh (Shell) statt bash und fuzzel (App-Menü) statt wofi (oder hatte mir das Pattern dmenu installiert?)

1. Sway allgemein

Als erstes habe ich festgestellt, dass bei diesem Sway-Pattern wirklich alles per Config-Dateien einzustellen ist. Es beginnt zu allererst mit dem Tastaturlayout. Eine Einstellung per Yast funktioniert ausdrücklich nicht! Auch hierfür begibt man sich in die Konfigiurationsdatei.

Es gibt eine Standard-Konfiguration von Sway unter /etc/sway/config

Diese holt man sich ins Benutzer-Konfigverzeichnis unter ~/.config

mkdir -p ~/.config/sway
cp /etc/sway/config ~/.config/sway/config

(solange ich mich unter Neovim nicht auskenne, verwende ich den mc mit eingebautem Editor)

1.1: Tastaturlayout

In die Datei habe ich dann irgendwo in Zeile 29 zwischen die Kommentare folgendes reingebastelt:

~/.config/sway/config:

input * {
    xkb_layout de
    xkb_variant nodeadkeys
    }

(funktioniert bei mir interessanterweise ohne "" um de...)

1.2 HiDPI

Als nächstes habe ich mir die Namen meiner Grafikkrtenausgänge besorgt:

Am Terminal:

swaymsg -t get_outputs

Mein HiDPI-Monitor ist an DP-1.

unter der bekannten ~/.config/sway/config hab ich unter der Wallpaper-Zeile bzw. Example configuration dann

 output "DP-1" scale 1.3

eingetragen. Ich bin kein Fan von zu winzigen Terminal-Ausgaben...

2. Kitty

2.1: Kitty über zypper installieren:

sudo zypper in kitty

2.2: Kitty als Default-Terminal einrichten:

~/.config/sway/config bearbeiten, Zeile 17 bearbeiten zu:

set $term kitty

(statt alacritty+Parameter)

(evtl. swaymsg reload im Terminal eingeben)

[Meta=Win]+Enter sollte nun immer kitty öffnen.

2.3 Kitty konfigurieren:

~/.config/kitty/kitty.conf bearbeiten

unter den font family-Block hab ich

font_size 13.0

eingefügt.

Und unter color scheme die Transparenz des Fensters auf 0.8 geändert:

 background_opacity 0.8

Cool.

(Jetzt ist alacritty eigentlich überflüssig. Da es Teil des installierten openSUSEway-Schemas ist, lässt es sich allerdings nicht so leicht entfernen. Mit einer Deinstallation des Schemas würde man wahrscheinlich auch andere wesentliche Dinge verlieren...

3. fuzzel als Application Launcher

3.1: fuzzel installieren:

sudo zypper in fuzzel

3.2: fuzzel bei Sway als Standard-Launcher eintragen:

~/.config/sway/config bearbeiten, Zeile 22:

set $menu fuzzel

(evtl. swaymsg reload im Terminal eingeben)

[WIN=META]+D sollte dann das fuzzel-Menü anzeigen

3.3 fuzzel auf openSUSEway optisch anpassen:

eine Textdatei ~/.config/fuzzel/fuzzel.ini anlegen

Meine Variante:

[colors]
background=0d1b1eff
text=edf6f9ff
match=52b788ff
selection=1e6865ff
selection-text=edf6f9ff
border=00a489ff

(Einfach so als quasi-vollständige Textdatei in die fuzzel.ini einfügen)

Damit hat man dann schonmal die Basis.

Ich habe dann noch die zsh mit ohmyzsh, autojump (statt z), powerlevel10k, zsh-autosuggestions und zsh-syntax-highlighting installiert.

Sieht insgesamt so aus mit zwei Monitoren:

Habe noch einmal etwas recherchiert.

zu 3) Window Manager

zu Sway am besten Waybar und fuzzel (als Anwndungsstarter) dazu installieren.

zu 4) Terminal

Beim Terminal würde ich nun doch auf Kitty gehen. Laut meinen Recherchen sollte Kitty besser mit TilingWMs wie Sway zurecht kommen. Ghostty hat dagegen Stärken auf Floating WMs. Es basiert auf GTK und integriert sich gut in Gnome, XFCE oder auch MacOS (was der Grund sein dürfte für die Verbreitung auf Youtube).

was ich mir auch noch angesehen habe:

9) Shell: die zsh ist Posix-Kompatibel, aber im Gegensatz zur Bash gut anpassbar. Hier gibt es wie bei Neovim einen Plugin-Manager: ohmyzsh. Empfohlene Pulgins: zsh-autosuggestions, zsh-syntax-highlighting, z, powerlevel10k...

Ergibt folgende Liste:

1. Sprache zum Lernen: Python
2. OS: Opensuse Tumbleweed als Basis-System
3. WM: Sway Window Manager
   1. Arbeitsflächen-Leiste: Waybar für Sway
   2. Starter für Sway: fuzzel
4. Shell: zsh (Liste ab hier umnummeriert)
   1. ohmyzsh als Pluginmanager, darüber installieren:
      1. zsh-autosuggestions
      2. zsh-syntax-highlighting
      3. z
      4. powerlevel10k
5. Terminal: kitty
6. Tool: Yazi File Manager
7. Editor/IDE: Neovim
   1. Plugin-Manager: Lazyvim
      1. $Empfohlene Plugins mit *
      2. $Sprach-Plugins für Python
8. Isolierte Umgebungen: Nix Shell/Paketmanager

Nach dem Installieren sitzt man wahrscheinlich erstmal wie ein Schwein vorm Uhrwerk...

Zunächst das Paket aus den Repos installieren:

sudo zypper in nix

Dies installiert das Paket bzw. Nix als Multiuser-Variante. Allerdings ist die Konfiguration danach alles andere als komplett.

Zunächst muss bei Multiuser der Nix-Daemon gestartet werden:

sudo systemctl status nix-daemon.socket nix-daemon.service
sudo systemctl start nix-daemon.socket nix-daemon.service
sudo systemctl enable nix-daemon.socket nix-daemon.service

Zum Laden der Pakete verwendet Nix Zertifikate, welche es aber unter Tumbleweed von selbst nicht findet. Daher sollte (zumindest am Anfang) die Umgebungsvariable NIX_SSL_CERT_FILE eingerichtet werden. D.h. man weist ihr den Pfad zum openSUSE-Zertifikatspeicher zu, indem man die Servicedatei bearbeitet:

sudo systemctl edit nix-daemon.service

Im nun gestarteten Editor den Override-Bereich der Textdatei (zwischen den drei ### und den drei ###) posten:

[Service]
Environment="NIX_SSL_CERT_FILE=/etc/ssl/ca-bundle.pem"

vi dann mit <Esc>, ":wp" verlassen

Das erste Hello World könnte somit jetzt erfolgreich heruntergeladen werden und laufen:

nix run nixpkgs#hello

Es wird "Hello, world!" ausgegeben.

"nix-shell -p hello" scheitert aber noch, da 'nixpkgs' nicht im Suchpfad liegt. Man kann sich zunächst mit

nix-shell -I nixpkgs=channel:nixos-unstable -p hello

behelfen.

Es werden zum Test zahlreiche Pakete in den lokalen Nix-Store (Paketspeicher) geladen. Wenn man die Shell so anlegt, gilt nach meinem Verständnis :

python3

Ruft das Tumbleweed-Python3 auf.

Der Clou:

gcc -v

zeigt, dass gcc aus dem lokalen Nix-Store kommt.

Mit

nix-shell -I nixpkgs=channel:nixos-unstable -p hello --pure

sorgt der --pure-Parameter dafür, dass man python3 nicht mehr aufrufen kann und man hat nach meinem Verständnis eine abgekapselte Nix-Shell. Was in eine Shell hinein installiert wird, kann man später z.B. über eine shell.nix -Datei festlegen!

Das oben genannte Problem mit der Unauffindbarkeit von nixpkgs ist ärgerlich und sollte sich mit einem ersten Update klären. Leider zerlegt es beim Aufruf von sudo die Umgebungsvariable für die Download-Zertifikate, sodass sich folgender Aufruf zum Updaten ergibt:

sudo -E NIX_SSL_CERT_FILE=/etc/ssl/ca-bundle.pem nix-channel --update

Hier ist dann die Frage, ob Nix schon auf einen Channel (sowas wie ein Repo) als Bezugsquelle für seine Pakete eingestellt ist.

Channel hinzufügen:

sudo nix-channel --add https://channels.nixos.org/nixos-unstable nixpkgs

Konfigurierte Channels anzeigen:

sudo nix-channel --list

jedenfalls sollte das Update möglich sein und sich die Hello-Shell auch auf kurzem Wege anlegen lassen:

nix-shell -p hello

oder auch

 nix-shell -p hello --pure

Behelfen kann man sich beim Update bezüglich der blöden Umgebungsvariable und sudo risikofreudigerweise durch das Bearbeiten der sudo-Konfiguration mit "sudo visudo". Etwas weiter unten, bei "Defaults env_keep" kann man NIX_SSL_CERT_FILE in der Aufzählung, mit Leerzeichen getrennt hinzufügen. Im Moment bin ich mir aber über die Konsequenzen noch nicht abschließend im Klaren, denn an der sudo-Konfiguration herumzuspielen ist immer riskant! Oder man legt sich einfach ein Alias an...