systemctl uses ANSI escape codes to underline text (
\e[4m) and then it also uses special escape codes – that Wikipedia classifies as “not in the standard”, but I haven’t looked it up – to *change the color of the underline*. That color change is barely noticeable in the first place.Some terminals don’t support this and now my systemctl output is *blinking* because of that.
gcr thing running with *debug logs enabled* that print stuff like “sending secret exchange: …”? Is this healthy?)
gcr thing running with *debug logs enabled* that print stuff like “sending secret exchange: …”? Is this healthy?)
~/bin that you use daily, but you haven’t edited them once in well over 10 years …
~/bin that you use daily, but you haven’t edited them once in well over 10 years …
Speaking of OS/2 … I just realized that Windows 3.x didn’t have icons, either. If I’m not mistaken, this only got added in Windows 95. In other words, OS/2 had this feature before Windows did, because at least OS/2 2.1 from 1993 had icons. Who would have thunk.
(Now I kind of want to know which system really introduced this feature.)
Speaking of OS/2 … I just realized that Windows 3.x didn’t have icons, either. If I’m not mistaken, this only got added in Windows 95. In other words, OS/2 had this feature before Windows did, because at least OS/2 2.1 from 1993 had icons. Who would have thunk.
(Now I kind of want to know which system really introduced this feature.)
> I like the looks of your window manager. That's using Wayland, right?
Oh, no. It’s still X11. All my recent Wayland comments resulted from me trying to switch, but I think it’s still too early. Being unable to use QEMU (because it can’t capture the mouse pointer) is a pretty big blocker for me. This is completely broken, it just happens to be unnoticeable with modern guest OSes, so it’s probably not a priority for devs.
(Not to mention that I would have to fork and substantially extend dwl in order to “replicate” my X11 WM. And then, after having done that, I’d have to follow upstream Wayland development, for which I don’t have the resources. Things would need to slow down before I can do that.)
> all that wasted space of the windows not making use of the full screen!!@1
Heh. I’ve been using tiling WMs for ~15 years now, so it’s actually kind of refreshing to see something different for a change. 😅
> Probably close to the older Windowses.
That particular theme is a ripoff of OS/2 Warp 3: https://movq.de/v/6c2a948882/s.png 😅
> We ran some similar brownish color scheme (don't recall its name) on Win95 or Win98
Oh god. Yeah, I wasn’t a fan of those, either. 🥴~
> I like the looks of your window manager. That's using Wayland, right?
Oh, no. It’s still X11. All my recent Wayland comments resulted from me trying to switch, but I think it’s still too early. Being unable to use QEMU (because it can’t capture the mouse pointer) is a pretty big blocker for me. This is completely broken, it just happens to be unnoticeable with modern guest OSes, so it’s probably not a priority for devs.
(Not to mention that I would have to fork and substantially extend dwl in order to “replicate” my X11 WM. And then, after having done that, I’d have to follow upstream Wayland development, for which I don’t have the resources. Things would need to slow down before I can do that.)
> all that wasted space of the windows not making use of the full screen!!@1
Heh. I’ve been using tiling WMs for ~15 years now, so it’s actually kind of refreshing to see something different for a change. 😅
> Probably close to the older Windowses.
That particular theme is a ripoff of OS/2 Warp 3: https://movq.de/v/6c2a948882/s.png 😅
> We ran some similar brownish color scheme (don't recall its name) on Win95 or Win98
Oh god. Yeah, I wasn’t a fan of those, either. 🥴~
https://movq.de/v/0e4af6fea1/s.png
GNOME, on the other hand, didn’t, at least to my old screenshots from 2007:
https://www.uninformativ.de/desktop/2007%2D05%2D25%2D%2Dgnome2%2Dlaptop.png
I switched to Linux in 2007 and no window manager I used since then had icons, apparently. Crazy. An icon-less existence for 18 years. (But yeah, everything is keyboard-driven here as well and there are no buttons here, either.)
Anyway, my draft is making progress:
https://movq.de/v/5b7767f245/s.png
I do like this look. 😊
https://movq.de/v/0e4af6fea1/s.png
GNOME, on the other hand, didn’t, at least to my old screenshots from 2007:
https://www.uninformativ.de/desktop/2007%2D05%2D25%2D%2Dgnome2%2Dlaptop.png
I switched to Linux in 2007 and no window manager I used since then had icons, apparently. Crazy. An icon-less existence for 18 years. (But yeah, everything is keyboard-driven here as well and there are no buttons here, either.)
Anyway, my draft is making progress:
https://movq.de/v/5b7767f245/s.png
I do like this look. 😊
X11 knows the data type “cardinal”. For example, the window property
_NET_WM_ICON (which holds image data for icons) is an array of “cardinal”. I am already not really familiar with that word and I’m assuming that it comes from mathematics:https://en.wikipedia.org/wiki/Cardinal_number
(It could also be a bird, but probably not: https://en.wikipedia.org/wiki/Cardinalidae)
We would probably call this an “integer” today.
EWMH says that icons are arrays of cardinals and that they’re 32-bit numbers:
https://specifications.freedesktop.org/wm-spec/latest-single/#id-1.6.13
So it’s something like
0x11223344 with 0x11 being the alpha channel, 0x22 is red, and so on.You would assume that, when you retrieve such an array from the X11 server, you’d get an array of
uint32_t, right?Nope.
Xlib is so old, they use
char for 8-bit stuff, short int for 16-bit, and long int for 32-bit:https://x.org/releases/current/doc/libX11/libX11/libX11.html#Obtaining_and_Changing_Window_Properties
That is congruent with the general C data types, so it *does* make sense:
https://en.wikipedia.org/wiki/C_data_types
Now the funny thing is, on modern
x86_64, the type long int is actually 64 bits wide.The result is that every pixel in a Pixmap, for example, is twice as large in memory as it would need to be. Just because Xlib uses
long int, because uint32_t didn’t exist, yet.And this is something that I wouldn’t know how to fix without breaking clients.
X11 knows the data type “cardinal”. For example, the window property
_NET_WM_ICON (which holds image data for icons) is an array of “cardinal”. I am already not really familiar with that word and I’m assuming that it comes from mathematics:https://en.wikipedia.org/wiki/Cardinal_number
(It could also be a bird, but probably not: https://en.wikipedia.org/wiki/Cardinalidae)
We would probably call this an “integer” today.
EWMH says that icons are arrays of cardinals and that they’re 32-bit numbers:
https://specifications.freedesktop.org/wm-spec/latest-single/#id-1.6.13
So it’s something like
0x11223344 with 0x11 being the alpha channel, 0x22 is red, and so on.You would assume that, when you retrieve such an array from the X11 server, you’d get an array of
uint32_t, right?Nope.
Xlib is so old, they use
char for 8-bit stuff, short int for 16-bit, and long int for 32-bit:https://x.org/releases/current/doc/libX11/libX11/libX11.html#Obtaining_and_Changing_Window_Properties
That is congruent with the general C data types, so it *does* make sense:
https://en.wikipedia.org/wiki/C_data_types
Now the funny thing is, on modern
x86_64, the type long int is actually 64 bits wide.The result is that every pixel in a Pixmap, for example, is twice as large in memory as it would need to be. Just because Xlib uses
long int, because uint32_t didn’t exist, yet.And this is something that I wouldn’t know how to fix without breaking clients.
$ pacman -Qi pinentry
Name : pinentry
Version : 1.3.1-5
Description : Collection of simple PIN or passphrase entry dialogs which
utilize the Assuan protocol
Optional Deps : gcr: GNOME backend [installed]
gtk3: GTK backend [installed]
qt5-x11extras: Qt5 backend [installed]
kwayland5: Qt5 backend
kguiaddons: Qt6 backend
kwindowsystem: Qt6 backend
And it’s probably a good thing that they’re optional. I wouldn’t want to have all that installed *all the time*.
$ pacman -Qi pinentry
Name : pinentry
Version : 1.3.1-5
Description : Collection of simple PIN or passphrase entry dialogs which
utilize the Assuan protocol
Optional Deps : gcr: GNOME backend [installed]
gtk3: GTK backend [installed]
qt5-x11extras: Qt5 backend [installed]
kwayland5: Qt5 backend
kguiaddons: Qt6 backend
kwindowsystem: Qt6 backend
And it’s probably a good thing that they’re optional. I wouldn’t want to have all that installed *all the time*.
https://movq.de/v/0034cc1384/s.png
Then I realized: Wait a minute, lots of applications don’t set an icon? And lots of other window managers don’t show these icons, either? Openbox, pekwm, Xfce, fvwm, no icons.
Looks like macOS doesn’t show them, either?!
Has this grown out of fashion? Is this purely a Windows / OS/2 thing?
https://movq.de/v/0034cc1384/s.png
Then I realized: Wait a minute, lots of applications don’t set an icon? And lots of other window managers don’t show these icons, either? Openbox, pekwm, Xfce, fvwm, no icons.
Looks like macOS doesn’t show them, either?!
Has this grown out of fashion? Is this purely a Windows / OS/2 thing?
What are the types in this example?
items:
- part_no: A4786
descrip: Water Bucket (Filled)
price: 1.47
quantity: 4
- part_no: E1628
descrip: High Heeled "Ruby" Slippers
size: 8
price: 133.7
quantity: 1
items is a dict containing … a list of two other dicts? Right?It is quite hard for me to grasp the *structure* of YAML docs. 😢
The big advantage of YAML (and JSON and TOML) is that it’s much easier to write code for those formats, than it is with XML.
json.loads() and you’re done.
What are the types in this example?
items:
- part_no: A4786
descrip: Water Bucket (Filled)
price: 1.47
quantity: 4
- part_no: E1628
descrip: High Heeled "Ruby" Slippers
size: 8
price: 133.7
quantity: 1
items is a dict containing … a list of two other dicts? Right?It is quite hard for me to grasp the *structure* of YAML docs. 😢
The big advantage of YAML (and JSON and TOML) is that it’s much easier to write code for those formats, than it is with XML.
json.loads() and you’re done.
pinentry, which is used to safely enter a password on Linux, has several frontends. There’s a GTK one, a Qt one, even an ncurses one, and so on.GnuPG also uses
pinentry. And you can configure your frontend of choice here in gpg-agent.conf.But what happens when you *don’t* configure it? What’s the default?
Turns out,
pinentry is a shellscript wrapper and it’s not even that long. Here it is in full:#!/bin/bash
# Run user-defined and site-defined pre-exec hooks.
[[ -r "${XDG_CONFIG_HOME:-$HOME/.config}"/pinentry/preexec ]] && \
. "${XDG_CONFIG_HOME:-$HOME/.config}"/pinentry/preexec
[[ -r /etc/pinentry/preexec ]] && . /etc/pinentry/preexec
# Guess preferred backend based on environment.
backends=(curses tty)
if [[ -n "$DISPLAY" || -n "$WAYLAND_DISPLAY" ]]; then
case "$XDG_CURRENT_DESKTOP" in
KDE|LXQT|LXQt)
backends=(qt qt5 gnome3 gtk curses tty)
;;
*)
backends=(gnome3 gtk qt qt5 curses tty)
;;
esac
fi
for backend in "${backends[@]}"
do
lddout=$(ldd "/usr/bin/pinentry-$backend" 2>/dev/null) || continue
[[ "$lddout" == *'not found'* ]] && continue
exec "/usr/bin/pinentry-$backend" "$@"
done
exit 1
Preexec, okay, then some auto-detection to use a toolkit matching your desktop environment …
… and *then* it invokes
ldd? To find out if all the required libraries are installed for the auto-detected frontend?Oof. I was sitting here wondering why it would use
pinentry-gtk on one machine and pinentry-gnome3 on another, when both machines had the exact same configs. Yeah, but different libraries were installed. One machine was missing gcr, which is needed for pinentry-gnome3, so that machine (and that one alone) spawned pinentry-gtk …
pinentry, which is used to safely enter a password on Linux, has several frontends. There’s a GTK one, a Qt one, even an ncurses one, and so on.GnuPG also uses
pinentry. And you can configure your frontend of choice here in gpg-agent.conf.But what happens when you *don’t* configure it? What’s the default?
Turns out,
pinentry is a shellscript wrapper and it’s not even that long. Here it is in full:#!/bin/bash
# Run user-defined and site-defined pre-exec hooks.
[[ -r "${XDG_CONFIG_HOME:-$HOME/.config}"/pinentry/preexec ]] && \
. "${XDG_CONFIG_HOME:-$HOME/.config}"/pinentry/preexec
[[ -r /etc/pinentry/preexec ]] && . /etc/pinentry/preexec
# Guess preferred backend based on environment.
backends=(curses tty)
if [[ -n "$DISPLAY" || -n "$WAYLAND_DISPLAY" ]]; then
case "$XDG_CURRENT_DESKTOP" in
KDE|LXQT|LXQt)
backends=(qt qt5 gnome3 gtk curses tty)
;;
*)
backends=(gnome3 gtk qt qt5 curses tty)
;;
esac
fi
for backend in "${backends[@]}"
do
lddout=$(ldd "/usr/bin/pinentry-$backend" 2>/dev/null) || continue
[[ "$lddout" == *'not found'* ]] && continue
exec "/usr/bin/pinentry-$backend" "$@"
done
exit 1
Preexec, okay, then some auto-detection to use a toolkit matching your desktop environment …
… and *then* it invokes
ldd? To find out if all the required libraries are installed for the auto-detected frontend?Oof. I was sitting here wondering why it would use
pinentry-gtk on one machine and pinentry-gnome3 on another, when both machines had the exact same configs. Yeah, but different libraries were installed. One machine was missing gcr, which is needed for pinentry-gnome3, so that machine (and that one alone) spawned pinentry-gtk …
- https://github.com/labwc/labwc/issues/1068
- https://github.com/labwc/labwc/pull/2933
(I think “Wayland compositor” is a misnomer. They are full-blown display servers that also do compositing, plus Wayland window management, plus X11 window management.)
One can only hope that all this eventually gets moved into the wlroots library. (I’m not sure if that’s possible, nor if people would want that.)
- https://github.com/labwc/labwc/issues/1068
- https://github.com/labwc/labwc/pull/2933
(I think “Wayland compositor” is a misnomer. They are full-blown display servers that also do compositing, plus Wayland window management, plus X11 window management.)
One can only hope that all this eventually gets moved into the wlroots library. (I’m not sure if that’s possible, nor if people would want that.)
(Unlike GNOME’s dconf, which uses some binary file format. Fun fact: The older and now deprecated gconf also used XML files.)
(Unlike GNOME’s dconf, which uses some binary file format. Fun fact: The older and now deprecated gconf also used XML files.)
Let’s try again next year. I don’t have the stamina. Death by a thousand paper cuts.
Can’t set up a meaningful taskbar: https://github.com/labwc/labwc/discussions/2924 (This is not a labwc issue, it’s a generic issue in the broader Wayland ecosystem.)
Let’s try again next year. I don’t have the stamina. Death by a thousand paper cuts.
Can’t set up a meaningful taskbar: https://github.com/labwc/labwc/discussions/2924 (This is not a labwc issue, it’s a generic issue in the broader Wayland ecosystem.)
Because of that recent storm on my blog, I had a peek at them. There’s a lot of garbage in there. For example, https://docs.freebsd.org/en/books/handbook/disks-virtual.html is supposed to refer to one of my blog posts …
What’s going on here?
Because of that recent storm on my blog, I had a peek at them. There’s a lot of garbage in there. For example, https://docs.freebsd.org/en/books/handbook/disks-virtual.html is supposed to refer to one of my blog posts …
What’s going on here?
> Bluesky: Users verify their age by adding a payment method or uploading a photo ID.
>
> Mastodon: Users verify their age by posting pictures of the vintage computer equipment in their homes.
https://beige.party/@maxleibman/114848276288629121
😏
> Bluesky: Users verify their age by adding a payment method or uploading a photo ID.
>
> Mastodon: Users verify their age by posting pictures of the vintage computer equipment in their homes.
https://beige.party/@maxleibman/114848276288629121
😏
Tech is no longer interesting. I need to find a new field.
Tech is no longer interesting. I need to find a new field.
I think my main takeaway is this: Knowing that technologies like Landlock/pledge/unveil exist and knowing that they are very easy to use, will probably nudge me into writing software differently in the future.
jenny was never meant to be sandboxed, so it can’t make *great* use of it. Future software might be different.
(And this is finally a strong argument for static linking.)
I think my main takeaway is this: Knowing that technologies like Landlock/pledge/unveil exist and knowing that they are very easy to use, will probably nudge me into writing software differently in the future.
jenny was never meant to be sandboxed, so it can’t make *great* use of it. Future software might be different.
(And this is finally a strong argument for static linking.)
>This extension was turned off because it is no longer supported
Thanks Google.
This browser was uninstalled because it absolutely sucks!
So only the first line should be a quote.
>This extension was turned off because it is no longer supported
Thanks Google.
This browser was uninstalled because it absolutely sucks!
So only the first line should be a quote.
$ setpriv \
--landlock-access fs \
--landlock-rule path-beneath:execute,read-file:/bin/ls-static \
--landlock-rule path-beneath:read-dir:/tmp \
/bin/ls-static /tmp/tmp/xorg.atom
The first argument
--landlock-access fs says that nothing is allowed.--landlock-rule path-beneath:execute,read-file:/bin/ls-static says that reading and executing that file is allowed. It’s a statically linked ls program (not GNU ls).--landlock-rule path-beneath:read-dir:/tmp says that reading the /tmp directory and everything below it is allowed.The output of the
ls-static program is this line:─rw─r──r────x 3000 200 07-12 09:19 22'491 │ /tmp/tmp/xorg.atom
It was able to read the directory, see the file, do
stat() on it and everything, the little x indicates that getting xattrs also worked.3000 and 200 are user name and group name – they are shown as numeric, because the program does not have access to /etc/passwd and /etc/group.Adding
--landlock-rule path-beneath:read-file:/etc/passwd, for example, allows resolving users and yields this:─rw─r──r────x cathy 200 07-12 09:19 22'491 │ /tmp/tmp/xorg.atom
$ setpriv \
--landlock-access fs \
--landlock-rule path-beneath:execute,read-file:/bin/ls-static \
--landlock-rule path-beneath:read-dir:/tmp \
/bin/ls-static /tmp/tmp/xorg.atom
The first argument
--landlock-access fs says that nothing is allowed.--landlock-rule path-beneath:execute,read-file:/bin/ls-static says that reading and executing that file is allowed. It’s a statically linked ls program (not GNU ls).--landlock-rule path-beneath:read-dir:/tmp says that reading the /tmp directory and everything below it is allowed.The output of the
ls-static program is this line:─rw─r──r────x 3000 200 07-12 09:19 22'491 │ /tmp/tmp/xorg.atom
It was able to read the directory, see the file, do
stat() on it and everything, the little x indicates that getting xattrs also worked.3000 and 200 are user name and group name – they are shown as numeric, because the program does not have access to /etc/passwd and /etc/group.Adding
--landlock-rule path-beneath:read-file:/etc/passwd, for example, allows resolving users and yields this:─rw─r──r────x cathy 200 07-12 09:19 22'491 │ /tmp/tmp/xorg.atom
setpriv on Linux supports Landlock.If this twt goes through, then restricting the filesystem so that jenny can only write to
~/Mail/twt, ~/www/twtxt.txt, ~/.jenny-cache, and /tmp works.
setpriv on Linux supports Landlock.If this twt goes through, then restricting the filesystem so that jenny can only write to
~/Mail/twt, ~/www/twtxt.txt, ~/.jenny-cache, and /tmp works.
https://git.suckless.org/st/file/x.c.html#l1984
The exact timings are configurable.
This is the PR that changed the timing in VTE recently (2023):
https://gitlab.gnome.org/GNOME/vte/-/issues/2678
There is a long discussion. It’s not a trivial problem, especially not in the context of GTK and multiple competing terminal widgets. st dodges all these issues (for various reasons).
https://git.suckless.org/st/file/x.c.html#l1984
The exact timings are configurable.
This is the PR that changed the timing in VTE recently (2023):
https://gitlab.gnome.org/GNOME/vte/-/issues/2678
There is a long discussion. It’s not a trivial problem, especially not in the context of GTK and multiple competing terminal widgets. st dodges all these issues (for various reasons).
My shell prompt and cursor look like this:
$ █
When I keep Enter pressed, I expect to see several lines like so:
$
$
$
$
$
$
$ █
With the affected terminal emulators, the lines actually show up in the following sequence. First, we have the original line:
$ █
Pressing Enter yields this as the next frame:
$
█
And then eventually this:
$
$ █
In other words, you can see the cursor jumping around very quickly, all the time.
Another example: Vim actually shows which key you just pressed in the bottom right corner. Keeping
j pressed to scroll through a file means I get to see a j flashing rapidly now.(I have no idea yet, why *exactly* XTerm in X11 is fine but flickering in Wayland.)
My shell prompt and cursor look like this:
$ █
When I keep Enter pressed, I expect to see several lines like so:
$
$
$
$
$
$
$ █
With the affected terminal emulators, the lines actually show up in the following sequence. First, we have the original line:
$ █
Pressing Enter yields this as the next frame:
$
█
And then eventually this:
$
$ █
In other words, you can see the cursor jumping around very quickly, all the time.
Another example: Vim actually shows which key you just pressed in the bottom right corner. Keeping
j pressed to scroll through a file means I get to see a j flashing rapidly now.(I have no idea yet, why *exactly* XTerm in X11 is fine but flickering in Wayland.)
name and class.Wayland (or rather, the XDG shell protocol – core Wayland knows nothing about this) only has a single field called
app_id.When you run X11 programs under Wayland, you use XWayland, which is baked into most compositors. Then you have to deal with all three fields.
Some compositors map
name to app_id, others map class to app_id, and even others directly expose the original name and class.Apparently, there is no consensus.
name and class.Wayland (or rather, the XDG shell protocol – core Wayland knows nothing about this) only has a single field called
app_id.When you run X11 programs under Wayland, you use XWayland, which is baked into most compositors. Then you have to deal with all three fields.
Some compositors map
name to app_id, others map class to app_id, and even others directly expose the original name and class.Apparently, there is no consensus.
SDL_VIDEODRIVER=wayland globally, because that breaks Wine again …
SDL_VIDEODRIVER=wayland globally, because that breaks Wine again …
SDL_VIDEODRIVER=wayland.
SDL_VIDEODRIVER=wayland.