tigervnc: vncserver@:1.service: Deactivated successfully just after start on gentoo

Tigervnc server starts and then stops immedietly. The solution was to go to /etc/X11/Sessions, and rename Xsession file:

cd /etc/X11/Sessions
mv ./Xsession Xsession_bkp
And restart the vncserver.

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 xfce4-sensors-plugin

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

bedrock linux: share getnoo's /etc/portage with stratas

For example file managers install in strta, e.g. mc, yazi, will not be able to go /etc/portage of gentoo. To fix that, share portage folder in

Add portage to [global] in /bedrock/etc/bedrock.conf: etc = adjtime, crypttab, default/grub, fstab, group, group+, group-, group.OLD, group.org, gshadow, gshadow+, gshadow-, gshadow.OLD, gshadow.org, hostname, hosts, login.defs, machine-id, modprobe.d/blacklist.conf, passwd, passwd+, passwd-, passwd.OLD, passwd.org, rc.local, resolv.conf, resolvconf/run, shadow, shadow+, shadow-, shadow.OLD, shadow.org, sudoers, portage
Then sudo brl apply

librewolf: dissable adding application for mailto links

about:config
Set: network.protocol-handler.external.mailto to false.

xterm: set font size

Create ~/.Xresources with the content:
! Use a truetype font and size.
xterm*faceName: Monospace
xterm*faceSize: 14
Run the following to take effect: xrdb -merge ~/.Xresources
From: https://askubuntu.com/a/1138738

gentoo: example make.use

# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /usr/share/portage/config/make.conf.example for a more
# detailed example.

COMMON_FLAGS="-O2 -pipe -march=native"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"
FCFLAGS="${COMMON_FLAGS}"
FFLAGS="${COMMON_FLAGS}"

# NOTE: This stage was built with the bindist USE flag enabled

# This sets the language of build output to English.
# Please keep this setting intact when reporting bugs.
LC_MESSAGES=C.UTF-8

RUSTFLAGS="${RUSTFLAGS} -C target-cpu=native"

MAKEOPTS="-j4 -l5"

USE="dist-kernel"

# Appending getbinpkg to the list of values within the FEATURES variable
FEATURES="${FEATURES} getbinpkg"
# Require signatures
FEATURES="${FEATURES} binpkg-request-signature"

ACCEPT_LICENSE="*"

EMERGE_DEFAULT_OPTS="--binpkg-respect-use=y"

gentoo: set --binpkg-respect-use in make.use

Add to make.use: EMERGE_DEFAULT_OPTS="--binpkg-respect-use=n

gnome-boxes from flatpak: file selection window does not show

I had that issue on gentoo running systemd with xfce4. Even though xdg-desktop-portal and xdg-desktop-portal-gtk portals were installed and running, gnome-boxes file selection window was not working. The solution was to set gtk portal by default:

create ~/.config/xdg-desktop-portal/portals.conf:

[preferred]
default=gtk
org.freedesktop.impl.portal.FileChooser=gtk


Open WebUI: Add your OpenCode Go subscription

For the connection url use: https://opencode.ai/zen/go/v1 and then your OpenCode Go API key

https://i.imgur.com/KU4yEsj.png