chroot: failed to run command ‘/bin/bash’: No such file or directory

You can specify different shell, e.g.: sudo chroot /mnt/nixos /bin/sh

xpra: More responsive remote connections

xpra start ssh://server/ --exit-with-children --start-child=terminator --encoding=jpeg --min-speed=100 --min-quality=0 --compress=1 --bandwidth-detection=yes --pixel-depth=16 --auto-refresh-delay=0 --video-scaling=2 --dpi=96
--min-speed — higher is faster. 100 is the maximum, meaning "always encode as fast as possible, never slow down for quality."

--min-quality — lower is faster. 30 means "allow aggressive quality reduction to save bandwidth." Setting it to 0 lets xpra reduce quality even further dynamically

Or run persistent server on the remote server

On the server: xpra start :100 --start-child=xfce4-terminal
On the client:
xpra attach ssh://curtin/:100 --encoding=jpeg --min-speed=100 --min-quality=0 --compress=1 --bandwidth-detection=yes --pixel-depth=16 --auto-refresh-delay=0 --video-scaling=2 --dpi=96

MATLAB on Arch Linux: java.lang.NullPointerException and MATLAB does not start

If MATLAB stopped launching after a recent Arch Linux system update and you see a java.lang.NullPointerException with a stack trace starting at DTSingleClientFrame.mainFrameCreated, likely reason could be a corrupted preferences folder.

You can confirm the issue by checking whether MATLAB works without the desktop:

matlab -nodesktop -nosplash

If that launches fine, the desktop preferences are to blame. The fix is simply to delete MATLAB's local preferences folder:
rm -rf ~/.matlab/R20*/
matlab

MATLAB will recreate the folder fresh on next launch and the desktop should start normally again. No reinstall needed.

picom: Sample confing in gentoo with xfce4 and nouveau dirver

Picom on Nouveau: Which Backend to Use If you're running the open-source nouveau NVIDIA driver and using the picom compositor, you've likely run into rendering glitches or crashes. The culprit is almost always the backend. Picom's GLX backend relies heavily on OpenGL, and nouveau's OpenGL support is incomplete. Stick to the xrender backend instead — it's slower, but stable. Create a config file at

~/.config/picom/picom.conf

with the following content:
backend = "xrender";

Vsync — disable, nouveau's support is unreliable
vsync = false;

Shadows
shadow = true;
shadow-radius = 7;
shadow-opacity = 0.75;
shadow-offset-x = -7;
shadow-offset-y = -7;

Fading
fading = true;
fade-in-step = 0.03;
fade-out-step = 0.03;

Opacity
inactive-opacity = 1.0;
frame-opacity = 1.0;
Then restart picom: pkill picom; picom -b
That's it. You trade some visual effects (blur requires GLX) for a stable desktop. If you ever switch to the proprietary NVIDIA driver, revisit the GLX backend for better performance.

gentoo: Extra packages for xfce4

sudo emerge -av xfce-extra/xfce4-whiskermenu-plugin xfce4-cpugraph-plugin xfce-extra/xfce4-notes-plugin x11-apps/xhost app-admin/system-config-printer xdg-desktop-portal-gtk

arch: keditfiletype missing

yay kde-cli-tools

gwenview: Does not start due to setting rendering to OpenGL

Delete its config file:
rm ~/.config/gwenviewrc

distrobox: Opening Images in Native GIMP from IrfanView Running Under Wine in Distrobox

I use IrfanView via Wine inside a Distrobox container and wanted its external editor feature to open images directly in native GIMP. IrfanView passes the image path in Windows format (Z:\home\home-folder\Pictures\photo.jpg), so a small Python script handles the conversion and launches GIMP. Sounds simple. It wasn't.

Two things needed fixing before GIMP would even start. First, GIMP's sandboxed image loader (glycin) uses bubblewrap, which cannot create user namespaces inside a container — fixed with GLYCIN_DISABLE_SANDBOX=1. Second, any process launched from the script died the moment the script exited, because Wine kills all child processes when its own child (the Python script) returns.

Even after solving those, GIMP crashed every time it tried to open a file, with a GTK3 assertion failure inside GtkFileChooserWidget. The same command worked perfectly from the shell. The environment variables were identical. The difference turned out to be invisible to env: Wine installs a seccomp filter on its processes, and that filter is inherited by every child process across fork and exec. No amount of environment tweaking or session detachment can clear an inherited seccomp filter. GTK's file chooser widget makes a syscall during initialisation that Wine's filter blocks, and GIMP crashes.

The fix is to launch GIMP as a transient systemd user service with systemd-run --user --no-block. A process started this way is owned by systemd, not Wine — clean process state, no inherited seccomp filter, completely outside Wine's process tree.

#!/usr/bin/python
import os, sys, subprocess

def convert_wine_path(p):
    return p.replace('\\', '/').replace('Z:', '')

env = os.environ.copy()
img_file = convert_wine_path(sys.argv[1]) if len(sys.argv) == 2 else None

cmd = [
    'systemd-run', '--user', '--no-block',
    '--setenv=GLYCIN_DISABLE_SANDBOX=1',
    f'--setenv=DISPLAY={env["DISPLAY"]}',
    f'--setenv=HOME={env["HOME"]}',
    f'--setenv=XDG_RUNTIME_DIR={env["XDG_RUNTIME_DIR"]}',
    '/usr/bin/gimp'
]
if img_file:
    cmd.append(img_file)

subprocess.run(cmd)


Save it somewhere on your Linux filesystem, point IrfanView's external editor to the Z: path equivalent, and it works. The same trick applies to any native Linux app you need to launch cleanly from within Wine.

gentoo: There was an error during CUPS operation: "No such file or directory".

This happend for me with gentoo, cups and hplip. Had to install filters:
emerge --ask net-print/cups-filters End then
systemctl restart cups

gentoo and distrobox: OCI runtime exec failed: exec failed: unable to start container process: error starting setns process: exec: already started

I have gentoo host, with systemd, nvidia and docker. When I want to create a distrobox image with systemd in the container, e.g.:
distrobox create --nvidia -i archlinux -n abox -H ~/home-abox --init --additional-packages "systemd"
I was getting: OCI runtime exec failed: exec failed: unable to start container process: error starting setns process: exec: already started
The solution was to use crun container runtime, instead of default runc. To do this

1. Install crun: emerge -av app-containers/crun
2. Create `/etc/docker/daemon.json` with the content: {
"runtimes": {
"crun": {
"path": "/usr/bin/crun"
}
},
"default-runtime": "crun"
}
3. Restart docker sudo systemctl restart docker