BaSzErr

2026-01-12_-_easy_emoji_under_linux

basz@undisclosed.example.com (basz) — Mon, 12 Jan 2026 19:55:04 +0000

2026-01-12 - easy emoji under linux

recently i was wondering what's the best way to type in emoji under linux. some key bindings would be nice, to the common ones… and it turned out that using Wayland and sway DM it's very easy! :)

1st we need a script that's using wtype to simulate inserting characters from keyboard. e.g.:

#!/bin/bash
set -euo pipefail
for name in "$@"
do
  case "$name" in
    "cold_swet")     wtype "😅" ;;
    "grimacing")     wtype "😬" ;;
    "grin")          wtype "😁" ;;
    "hushed")        wtype "😯" ;;
    "innocent")      wtype "😇" ;;
    "rotfl")         wtype "🤣" ;;
    "scream")        wtype "😱" ;;
    "skull")         wtype "💀" ;;
    "sunglasses")    wtype "😎" ;;
    "thinking")      wtype "🤔" ;;
    "speak_no_evil") wtype "🙊" ;;
    "hear_no_evil")  wtype "🙉" ;;
    "see_no_evil")   wtype "🙈" ;;
    "spock")         wtype "🖖" ;;
    "thumbs_up")     wtype "👍" ;;
    "thumbs_down")   wtype "👎" ;;
    "rocket")        wtype "🚀" ;;
    "poo")           wtype "💩" ;;
    "rolling_eyes")  wtype "🙄" ;;
    "fire")          wtype "🔥" ;;
    "snowman")       wtype "⛄" ;;
    *)               wtype "?"  ;;
  esac
done

then add key bindings to Sway's config (i use right alt, as this is default for inserting polish national characters, too) in ~/.config/sway/config:

[...]
# emoji
bindsym Mod5+g       exec emoji grin
bindsym Mod5+shift+g exec emoji grimacing
bindsym Mod5+r       exec emoji rotfl
bindsym Mod5+Shift+r exec emoji rocket
bindsym Mod5+p       exec emoji spock
bindsym Mod5+Shift+p exec emoji poo
bindsym Mod5+t       exec emoji thinking
bindsym Mod5+h       exec emoji scream
bindsym Mod5+Shift+h exec emoji hushed
bindsym Mod5+u       exec emoji thumbs_up
bindsym Mod5+d       exec emoji thumbs_down
bindsym Mod5+l       exec emoji cold_sweat
bindsym Mod5+k       exec emoji skull
bindsym Mod5+j       exec emoji sunglasses
bindsym Mod5+i       exec emoji innocent
bindsym Mod5+y       exec emoji rolling_eyes
bindsym Mod5+f       exec emoji fire
bindsym Mod5+w       exec emoji snowman
[...]

…and off we go! :)

you might have noticed that not all emoji have a binding. that's ok, as you can still use the script from command line with e.g.: emoji fire and you get your character inserted where needed! :)

also a note – while in theory you could put wtype directly to Sway's config, it's make it harder to read, as there are no inline comments and in text mode, many emojis are hard to read or do not show at all (i.e. just a hex code).

2026-01-11_-_redundant_internet_at_home

basz@undisclosed.example.com (basz) — Sun, 11 Jan 2026 12:25:29 +0000

2026-01-11 - redundant internet at home

for some years now i work 95% remotely, visiting office only a few times a year. this means i want to have network connection as stable as it can be. while i do have fiber optics and while it's almost perfect wrt availability, 1-2 times a year there are moment when internet is down… and with my luck, this can strike in a very bad moment.

to combat that i decided to get a redundant network connection. my 2nd ISP is a mobile provider. therefor i have 2 WANs – the main via my PC-router one and a RasPi with USB modem attached. on a home router i have a simple script that pings a set a predefined IPs to check if internet connection is there or not. if it fails, it moves to a secondary link. it goes like this:

#!/bin/bash
set -eu -o pipefail
app=$(basename "$0")
 
function is_alive # <0:iface>
{
  local i=1
  local n=5
  for addr in $(sort -R /etc/startup/allowed_external_hosts.ips | head "-$n")
  do
    timeout 4 ping -c 2 -I "$1" "$addr" > /dev/null 2>&1 && return 0
    echo "$app: ping $addr via $1 failed ($i/$n)"
    ((++i))
  done
  echo "$app: looks like $1 is dead..."
  return 1
}
 
function set_default # <0:metric_pri> <1:metric_sec>
{
  echo "$app: setting $if_pri=$1 vs. $if_sec=$2"
  (
    set +e
    set -x
    ip r del "${rule_pri[@]}"
    ip r del "${rule_sec[@]}"
    ip r add "${rule_pri[@]}" metric "$1"
    ip r add "${rule_sec[@]}" metric "$2"
    systemctl stop  openvpn
    systemctl start openvpn
    sleep 2 # give VPN some time to reconnect, so that the routing table is shown properly
    ip r
  )
  echo "$app: switchover completed"
}
 
function set_pri
{
  set_default 2000 3000
}
 
function set_sec
{
  set_default 3000 2000
}
 
if_pri=wan0
if_sec=wan1
 
rule_pri=( $(ip r | grep "^default .* $if_pri\>" | sed -e 's/ metric .*//' -e 's/ *$//') )
rule_sec=( $(ip r | grep "^default .* $if_sec\>" | sed -e 's/ metric .*//' -e 's/ *$//') )
 
current=unknown
 
trap set_pri EXIT
 
while sleep 1
do
  if is_alive "$if_pri"
  then
    if [ "$current" = pri ]
    then
      sleep 3
    else
      set_pri
      current=pri
    fi
    continue
  fi
 
  if is_alive "$if_sec"
  then
    if [ "$current" = sec ]
    then
      sleep 11
    else
      set_sec
      current=sec
    fi
    continue
  fi
 
  echo "$app: both interfaces seem to be dead - that's bad..."
done

the script is meant to be ran as a systemd service.

since pinging is possible via an explicitly-specified interface, we can check if a given link is up or not, w/o changing any network settings. then, if link switch is required, it's enough to swap metric of 2 interfaces (here: wan0 and wan1) and restart VPN, so that it connects via a new interface… and that's it. works like a charm for a long time now, with fairly fast switching in case of a problem. it's also quite noise resistant, as many different IPs are used randomly and multiple IPs are checked before deciding to fail over.

2026-01-11_-_rsync_and_defaults

basz@undisclosed.example.com (basz) — Sun, 11 Jan 2026 11:55:55 +0000

2026-01-11 - rsync and defaults

i really like rsync. there's sth brilliant in how it's (conceptually) simple and yet so powerful. there are however gotchas. recently i've noticed, when i sync data between some of my machines, there are certain files that are ~always re-synced (despite not being changed) as well as there are files that sync once, and then cause errors to sync after that.

to debug this it's worth using –itemize-changes that outputs a reason why a given file was synced. format is a bit cryptic, but after a moment with docs, it turned out that there's a bit of time offset (we're talking some tens of milliseconds, to be clear!) between source and target machines. this caused those “unfortunate” files to be always synced. the answer? use –times flag to rsync, so that it also copies creation / modification times from source. this way time offset between machines does not matter. that solved the 1st problem.

the second one is… odd. turns out that git does not give write permissions to object files in .git dir, as these are not expected to ever change after writing. fine locally, but a bit problematic when rsyncing repo, as there the file can change (e.g. resuming previous partial send). to fix this one –chmod=u+rw was added to rsync, so that remote copy has always R/W access for user at least. this allows to error-less sync things.

nice. these were quite some discoveries to be made. my only question – could we ask for a better defaults? the current ones just cause confusion…

btw: more rsync tips can be found on help_cmds repo, as usual.

2026

basz@undisclosed.example.com (basz) — Sun, 11 Jan 2026 11:46:30 +0000

2026

2025-10-10_-_spectrograms_of_different_light_sources

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 20:25:32 +0000

2025-10-10 - spectrograms of different light sources

after discovering project 326 YT channel i came across a review of dirt cheap spectrometer (see also part 2) manufactured by an individual in china. actually it looked quite impressive and with a price tag of 50€ there really did not need any more convincing… so this year i bought my 1st spectrometer. this blog post is a collection of samples and some interesting observations made with it.

device

little garden spectrometer¹⁾ came nicely packed, and fairly fast (~1w time). some of the more interesting parameters are:

spectrum range: 340nm-1050nm
1nm prevision for visible light
1-3nm outside of visible light

i'll not get into internal workings, though it's actually very interesting. i highly recommend the linked review videos for more details.

SW setup

from protocol PoV, the device is nothing more than a webcam. however to be able to interpret the white dots, a SW package is needed. it also need to be calibrated.

the SW package is a modified theremino, that has some improvements to work best with this device.

it' over a quarter of century since i'd don't use Windows as my primary OS. this also means i'm _very_ uncomfortable running any binary SW. in this case the SW is also only runnable for windows. so for start i decided to run it inside a VM.

take 1: Win XP

since it runs on windows (XP), i decided to use a VM for that. TL;DR it took me so much time to try to run a USB camera there it actually turned out to be faster to use linux + wine. i'll spare you the frustration of dealing with XP (those were some truly dark ages back then).

take 2: linux + wine

start as usual: qemu + debian:13 base. example command to run the tool:

# this gets the camera device:
camera_re=" 0c68:6464 Sonix Technology Co\., Ltd\. USB 2\.0 Camera"
dev=$(lsusb | grep "$camera_re" | awk '{ print $2 "/" $4 }' | tr -d :)
 
# here we start the VM:
qemu-system-x86_64 \
  -enable-kvm \
  -vga virtio \
  -drive file=disk.qcow2 \
  -m 4G -smp 4 \
  -usb -device usb-ehci,id=ehci -device qemu-xhci \
  -nic user,model=virtio-net-pci,hostfwd=tcp:127.0.0.1:22017-:22
  -device usb-host,hostdevice="/dev/bus/usb/$dev"

once OS is there, install X11 and some light graphical env. you can also get mplayer to ensure camera is working properly:

mplayer -tv "driver=v4l2:width=1920:height=1080:device=/dev/video0" -vo xv tv://

if all is fine, it's time to install wine and enable 32-bit support:

apt install wine wine32:i386 winetricks

since we need 32-bit app support, make sure you have these in env at all times:

export WINEARCH=win32
export WINEPREFIX=~/.wine32

now it's time to configure wine itself (the defaults are fine):

winecfg

and install old .NET version (echos of XP pains are back):

# install:
winetricks dotnet40 gdiplus
# confirm it's there:
winetricks list-installed

ok - now it's time to start the show! :)

export WINEARCH=win32
export WINEPREFIX=~/.wine32
# start from within the SW package from google drive, linked above:
wine theremino.exe

calibration

we're almost there. once the application is up, you need to calibrate it. the instructions and video tutorials go into details. TL;DR is that you need:

connect fluorescent light
let it heat up (~1 min is enough)
shine fluorescent light onto the device, to capture spectrogram
mark 436nm and 546nm peaks, as seen below

once the calibration is done – you're off to the races! :)

measurements

this section contains some measurements from different light sources i found around, with a comments… and some unexpected findings. :)

click on an image to enlarge it.

daylight

as you can see, there's quite a bit of IR and some UV-A.

a classic one. interesting as a reference for other sources.

daylight behind a double window

common wisdom is that glass blocks UV… and the first surprise – yes, it blocks UV… but not a close-UV.

candle

many times i've heard ppl saying natural fire light is similar to sunlight, so it's “better” (TM?). well – when you look into spectrogram and compare to sun's light, you can see it's actually very different. while overall shape looks similar, it's heavily shifter towards IR. in fact - half of the spectrum is outside of a visible range (heat! surprise! surprise!). so it's nice, it's warm… and it's nothing like a sun's light. everyone plz deal with it. ;)

halogen

another surprise – halogen light looks almost like a candle light! just must less bright (ok - my halogen light was just a small, desk lamp). here also big chunk is emitted as IR.

red laser (pointer)

well – very much as expected. 1, sharp peak at the reference frequency / wavelength (659nm).

green laser (pointer)

nope. :D i do not have one. nevertheless i decided to put a comment why it is so, as a word of warning.

these are commonly done as a charge-pump in IR, that causes emission in a visible light. this means that aside from obvious green peak, there's another one in IR (aka: invisible) range. this can potentially be dangerous to eyes, as there's much more energy emitted by these, than you can see. a silent trap, if not made correctly (i.e. with an IR filter). this is why i decided to not buy one.

LEDs

here are some LEDs i found laying around.

5mm blue

it clearly shows a difference between LED and laser – peak is more bell-shaped (centered around 466nm) than just a sharp spike. however interestingly – it's actually very bright. we'll get back to this very soon…

before we move one, note also a much smaller, 927nm “peak”. this is a second-order diffraction – i.e. an artifact of the measurement process. we can ignore it – it's not really there.

5mm green

571nm. similar in idea to blue, just at a different frequency… and much, much dimmer. interestingly enough – the difference is not as prominent with a naked eye (even though it's clearly visible). the reason is that human sight (as most other senses) is logarithmic – not linear.

5mm red

632nm. when it comes to brightness, somewhere in between blue and green.

5mm yellow

590nm, similar in brightness to red LED. again – visually seems a bit dimmer, than it actually is.

white

so… we have: R, G and B… RGB! so we have white, by putting all 3 in the same die, right? well, actually – no!

in fact white LEDs work in a completely different manner. it's being driven by a 1-color, bright LED that hits luminophore layer, that emits a wide spectrum. looking at the spectrograms below, you can see that blue is the weapon of choice. remember how bright it was, compared to other LEDs, driven by similar current? there you have a practical application of this effect.

note that this also explain why RGB-LEDs are less common than RGBW-LEDs. it's just that “white LED” is it's own, separate channel, to give better mixed (and brighter) light.

as a nice side effect this also means that LED light is also much closer to the natural sun light, than a candle! the only differences are no IR component and a dip between blue (driving) and green+ bands (stimulated) – a band gap.

home light

phone light

5mm white

IR 850nm

near IR. this one is not visible with a naked eye, but can still be captured by a cellphone's camera, as slightly brighter spot.

declared as 850nm, measured as 844nm. even though it's already out of visible range, the precision is still quite good (though a bit below declared values).

IR 940nm

farther IR. this can neither be visible by an eye, not my a phone's camera. some ESP32 night-vision cameras have this range, so it's a perfect lighting for nighttime conditions, as it does not draw attention, yet still makes target visible. because of that it is however a bit tricky to work with, as it's not visible to usual debug tools at hand, so it's hard to tell if lighting is correct, unless the final camera is used.

declared as 940nm and measured as 943nm – very good and within the spec.

UV LED 395nm

this one is no joke! 395nm is on the edge of visible spectrum, so that you can only see a small glow, despite flashlight being very bright. this is obviously dangerous, as it can damage your eyes.

just to give you a sense of how much power the flashlight in question emits – a few seconds to shining over “glow in the dark” printed block made it shine so bright in visible spectrum, i do not think i have ever seen it so bright before, even when left on a natural sunlight!

the flashlight came with “protective googles”. while the whole set was rather on a cheaper side, i had my doubts in how good the googles actually are, so just in case, used to prepare an object i needed to “charge”, close my eyes and only then turn flashlight on. now, equipped with a proper measuring tool i can finally check the googles, to do visual inspections.

flashlight

394nm measured for declared 395nm – spot on! the spike is _huge_. you can tell there's _a lot_ of energy pumped there. the 788nm and 1188nm are 2nd (394*2 == 788) and 3rd (394*3 == 1182) order diffractions and thus can be skipped.

through the protective glasses

now that's impressive! there's literally nothing but a background noise! all the UV power is gone. the glasses not only actually work, but work very well. now i know i can safely use these to protect my sight.

summary

spectroscopy is fun! since you made it hear, i'm positive you agree. :) it was super interesting experience for myself and also fun for kids to watch mesmerizing, colorful plots changing with the light sources. at a 50€ price tag there's no excuse to give it a shot! go for it… as soon as the device is back in stock, that is. ;)

¹⁾

before you roll your eyes on the name – in chinese “little garden” is a place of contemplation, meditation or hobby. this is the reference here.

uv_led_395nm_filtered.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 20:21:00 +0000

uv_led_395nm.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 20:17:20 +0000

led_ir_940nm.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 20:07:48 +0000

led_ir_850nm.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 20:06:32 +0000

led_white.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 20:05:32 +0000

white_led_phone.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 20:04:55 +0000

home_led_lighting.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 20:03:14 +0000

led_yellow.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 19:55:29 +0000

led_red.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 19:54:01 +0000

led_green.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 19:47:48 +0000

led_blue.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 19:46:34 +0000

laser_pointer_red.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 19:42:26 +0000

halogen_light.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 19:40:10 +0000

candle_light_1.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 19:37:02 +0000

sunlight_behind_double_window.png

basz@undisclosed.example.com (basz) — Fri, 10 Oct 2025 19:34:34 +0000