Recent changes to this wiki. Not to be confused with my history.

Complete source to the wiki is available on gitweb or by cloning this site.

fix typo, thanks patapon
diff --git a/blog/2022-06-17-matrix-notes.md b/blog/2022-06-17-matrix-notes.md
index 30ffc4a5..bc44dcc6 100644
--- a/blog/2022-06-17-matrix-notes.md
+++ b/blog/2022-06-17-matrix-notes.md
@@ -494,7 +494,7 @@ name (e.g. `foo`), and then that room will be available on your
 `example.com` homeserver as `#foo:example.com`.)
 
 So a room doesn't belong to a server, it belongs to the federation,
-and anyone can join the room from any serer (if the room is public, or
+and anyone can join the room from any server (if the room is public, or
 if invited otherwise). You can create a room on server A and when a
 user from server B joins, the room will be replicated on server B as
 well. If server A fails, server B will keep relaying traffic to

link to doctorow's reviews
diff --git a/hardware/laptop/framework-12th-gen.md b/hardware/laptop/framework-12th-gen.md
index 1cf8f3e5..00d1b5db 100644
--- a/hardware/laptop/framework-12th-gen.md
+++ b/hardware/laptop/framework-12th-gen.md
@@ -186,7 +186,8 @@ the laptop.
 
  * the 11th gen had good reviews: [Ars Technica](https://arstechnica.com/gadgets/2021/07/frameworks-new-lightweight-modular-laptop-delivers-on-its-promises/), [Fedora
    developer](https://www.scrye.com/wordpress/nirik/2021/08/29/frame-work-laptop-the-hyperdetailed-fedora-review/), [iFixit teardown](https://www.ifixit.com/News/51614/framework-laptop-teardown-10-10-but-is-it-perfect), [phoronix](https://www.phoronix.com/scan.php?page=article&item=framework-laptop&num=1), amazing
-   keyboard and touchpad, according to [Linux After Dark][linux-after-dark-framework] ; more
+   keyboard and touchpad, according to [Linux After Dark][linux-after-dark-framework], [most
+   exciting laptops I've ever broken](https://pluralistic.net/2022/11/13/graceful-failure/#frame) (Cory Doctorow) ; more
    critical review from an[OpenBSD developer](https://jcs.org/2021/08/06/framework)
 
  * the EC (Embedded Controller) is [open source](https://github.com/FrameworkComputer/EmbeddedController) so of course

another day, another (sway) bug
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 954bc0f3..e9859960 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -1294,6 +1294,24 @@ making the server better.
 [documented how to make the change in Puppet]: https://gitlab.com/anarcat/puppet/-/blob/main/site-modules/profile/manifests/pipewire.pp
 [Arch wiki page about Pipewire]: https://wiki.archlinux.org/title/PipeWire#Sound_does_not_automatically_switch_when_connecting_a_new_device
 
+## Keypress drops
+
+Sometimes I lose keyboard presses. This correlates with the following
+warning from Sway:
+
+    déc 06 10:36:31 curie sway[343384]: 23:32:14.034 [ERROR] [wlr] [libinput] event5  - SONiX USB Keyboard: client bug: event processing lagging behind by 37ms, your system is too slow 
+
+... and corresponds to an [open bug report in Sway](https://github.com/swaywm/sway/issues/5423). It seems the
+"system is too slow" should really be "your compositor is too slow"
+which seems to be the case here on this older system
+([[hardware/curie]]). It doesn't happen often, but it does happen,
+particularly when a bunch of busy processes start in parallel (in my
+case: a linter running inside a container and `notmuch new`).
+
+The [proposed fix](https://github.com/swaywm/sway/pull/6994) for this in Sway is to gain real time privileges
+and add the `CAP_SYS_NICE` capability to the binary. We'll see how
+that goes in Debian once 1.8 gets released and shipped.
+
 # Improvements over i3
 
 ## Tiling improvements

document my issues (and todo) with the ethernet card
diff --git a/hardware/laptop/framework-12th-gen.md b/hardware/laptop/framework-12th-gen.md
index d032444d..1cf8f3e5 100644
--- a/hardware/laptop/framework-12th-gen.md
+++ b/hardware/laptop/framework-12th-gen.md
@@ -1411,6 +1411,49 @@ One thing that is still missing is the [charge threshold data](https://community
 accessible](https://community.frame.work/t/battery-charge-control-thresholds-in-sysfs/21385/5?u=anarcat) in August, stay tuned? This would also make it possible
 implement [hysteresis support](https://community.frame.work/t/battery-charging-hysteresis-support/23495).
 
+### Ethernet expansion card
+
+The [Framework ethernet expansion card](https://frame.work/products/ethernet-expansion-card) is a fancy little doodle:
+"2.5Gbit/s and 10/100/1000Mbit/s Ethernet", the "clear housing lets
+you peek at the RTL8156 controller that powers it". Which is another
+way to say "we didn't completely finish prod on this one, so it kind
+of looks like we 3D-printed this in the shop"....
+
+The card is a little bulky, but I guess that's inevitable considering
+the RJ-45 form factor when compared to the thin Framework laptop.
+
+I have had a [serious issue](https://community.frame.work/t/ethernet-expansion-card-is-not-connecting/23866) when trying it at first: the link LEDs
+just wouldn't come up. I made a full bug report [in the forum](https://community.frame.work/t/ethernet-expansion-card-is-not-connecting/23866) and
+with upstream support, but eventually figured it out on my own. It's
+(of course) a power saving issue: if you reboot the machine, the links
+come up when the laptop is running the BIOS POST check and even when
+the Linux kernel boots.
+
+I [figured out](https://community.frame.work/t/ethernet-expansion-card-is-not-connecting/23866/11?u=anarcat) that the problem is likely related to the
+`powertop` service which I run at boot time to tweak some power saving
+settings. In particular, this:
+
+    echo 'on' > '/sys/bus/usb/devices/4-2/power/control'
+
+... is a good workaround to bring the card back online. You can even
+return to power saving mode and the card will still work:
+
+    echo 'auto' > '/sys/bus/usb/devices/4-2/power/control'
+
+Other than that, I haven't been able to max out the card because I
+don't have other 2.5Gbit/s equipment at home, which is strangely
+satisfying. But running against [[my|hardware/octavia]] Turris Omnia
+router, I could pretty much max a gigabit fairly easily:
+
+    [ ID] Interval           Transfer     Bitrate         Retr
+    [  5]   0.00-10.00  sec  1.09 GBytes   937 Mbits/sec  238             sender
+    [  5]   0.00-10.00  sec  1.09 GBytes   934 Mbits/sec                  receiver
+
+The card doesn't require any proprietary firmware blobs which is
+surprising. Other than the power saving issues, it just works.
+
+TODO: do power usage tests, suspend and idle.
+
 ## Proprietary firmware blobs
 
 The framework does need proprietary firmware to operate. Specifically:

engelbart quote, unchecked
diff --git a/fortunes.txt b/fortunes.txt
index 50733f7c..c638adc5 100644
--- a/fortunes.txt
+++ b/fortunes.txt
@@ -1199,3 +1199,7 @@ countries to develop in different ways. The telephone extends the
 voice, but also amputates the art of penmanship gained through regular
 correspondence.
                         — Marshall McLuhan, Understanding Media
+%
+If ease of use was the ultimate aim for a tool,
+the bicycle would never have evolved beyond the tricycle.
+                        — Doug Engelbart, 1925-2013

another cool hack
diff --git a/hardware/laptop/framework-12th-gen.md b/hardware/laptop/framework-12th-gen.md
index 6d9cf3d0..d032444d 100644
--- a/hardware/laptop/framework-12th-gen.md
+++ b/hardware/laptop/framework-12th-gen.md
@@ -1705,6 +1705,7 @@ long road trip across the continental US.
    * [ethernet](https://frame.work/ca/en/products/ethernet-expansion-card) (official, [back-order](https://twitter.com/FrameworkPuter/status/1569859445991292928) as of 2022-09-13)
    * [votes seem to go towards Ethernet and full-sized SD card
      reader](https://community.frame.work/t/what-new-expansion-card-types-do-you-want-to-see-released/193)
+   * [3D printed expansion card holder](https://www.printables.com/model/328421-framework-laptop-expansion-card-holder)
    * check out [this forum category](https://community.frame.work/c/developer-program/expansion-card/90) for a cornucopia of those
 
  * upstream resources:

document louise
diff --git a/hardware/louise.md b/hardware/louise.md
new file mode 100644
index 00000000..892f6416
--- /dev/null
+++ b/hardware/louise.md
@@ -0,0 +1,4 @@
+Replica of [[fumiko]]. Named after [Louise Michel](https://fr.wikipedia.org/wiki/Louise_Michel) - anarchiste de
+la commune de Paris, première à arborer le drapeau noir.
+
+[[!tag node]]
diff --git a/services/dns.mdwn b/services/dns.mdwn
index 68f8b418..c39777e1 100644
--- a/services/dns.mdwn
+++ b/services/dns.mdwn
@@ -72,6 +72,7 @@ femmes. Exemples utilisés:
 
  * [[hardware/angela]] ([Davis](https://en.wikipedia.org/wiki/Angela_Davis))
  * [[hardware/bell]] ([Hooks](https://en.wikipedia.org/wiki/Bell_hooks))
+ * [[hardware/louise]] ([Michel](https://fr.wikipedia.org/wiki/Louise_Michel)
  * ([Margaret](https://en.wikipedia.org/wiki/Margaret_Atwood)) [[hardware/atwood]]
  * ([Marie](https://en.wikipedia.org/wiki/Marie_Curie)) [[hardware/curie]]
  * ([Richard](https://en.wikipedia.org/wiki/Richard_Dawkins)) dawkins
@@ -112,8 +113,6 @@ Les noms suivants pourraient être utilisés pour de futures machines:
  * [Margaret Hamilton][] - developed the on-board flight software for NASA's Apollo program
  * [Ada Lovelace](https://en.wikipedia.org/wiki/Ada_Lovelace) - first programmer
  * [Grace Hopper](https://en.wikipedia.org/wiki/Grace_Hopper) - inventor of the compiler and linker
- * [Louise Michel](https://fr.wikipedia.org/wiki/Louise_Michel) - anarchiste de la commune de Paris, première à
-   arborer le drapeau noir
  * [Séverine](https://fr.wikipedia.org/wiki/S%C3%A9verine) - journaliste, féministe, première femme à diriger un
    grand quotidien en France
  * [Sojourner Truth](https://en.wikipedia.org/wiki/Sojourner_Truth) - abolotionist, first black women to win a

add missing node tags
diff --git a/hardware/atwood.md b/hardware/atwood.md
index f27ab3f9..70a00ecb 100644
--- a/hardware/atwood.md
+++ b/hardware/atwood.md
@@ -1 +1,3 @@
 Turris mox router, named after Margaret Atwood.
+
+[[!tag node]]
diff --git a/hardware/bell.md b/hardware/bell.md
index 3a01593d..1c95e765 100644
--- a/hardware/bell.md
+++ b/hardware/bell.md
@@ -23,3 +23,5 @@ drawer. It's running Debian "jessie" 8 with *some* "stretch"
 was from 2017, running the Linux kernel 3.16.0. Incredibly, this OS is
 *still* supported by [Debian LTS](https://wiki.debian.org/LTS), until 2025 for a [limited set of
 packages](https://www.freexian.com/lts/extended/docs/debian-8-support/).
+
+[[!tag node]]
diff --git a/hardware/fumiko.md b/hardware/fumiko.md
index f2aab090..7693cfbf 100644
--- a/hardware/fumiko.md
+++ b/hardware/fumiko.md
@@ -38,3 +38,5 @@ then on the master:
 then on fumiko again:
 
     puppet agent --test
+
+[[!tag node]]

found bell
diff --git a/hardware/bell.md b/hardware/bell.md
new file mode 100644
index 00000000..3a01593d
--- /dev/null
+++ b/hardware/bell.md
@@ -0,0 +1,25 @@
+Bell is named after [Bell Hooks](https://en.wikipedia.org/wiki/Bell_hooks). It's an old Panasonic Toughbook
+CF-W5. The [Panasonic landing page](https://na.panasonic.com/us/computers-tablets-handhelds/computers/laptops/toughbook-cf-w5) is utterly useless other than
+to say it's "discontinued". [According to small-laptops.com](https://www.small-laptops.com/panasonic-toughbook-w5/), it's
+"being discontinued" since 2008, with an original tag price of 2269$
+(!). It was reviewed positively by [Wired](https://www.wired.com/2007/01/review-panasoni/) and [ZDNet](https://www.zdnet.com/product/panasonic-toughbook-cf-w5/) in 2007 (!!).
+
+The [Panasonic wiki has full specs](https://panasonic.fandom.com/wiki/CF-W5#Other_Infomation), which include:
+
+ * CPU: Intel Core Duo 1.06GHz
+ * RAM: 512MB, upgraded to 2GB
+ * Storage: 150GB [Hitachi HTS54161 HDD](https://www.hdsentinel.com/storageinfo_details.php?lang=en&model=HITACHI%20HTS541616J9SA00) which, amazingly, still
+   works
+ * Display: 12.1" 1024x768 TFT LCD
+ * PC card, SD card reader
+ * weird 83-keys keyboards with japanese keys
+ * D-Sub 15-pin video output
+ * 56k Modem (!!) and 10/100 ethernet
+ * 2.9lbs
+
+This is one of my many spare laptops that I have lying around in a
+drawer. It's running Debian "jessie" 8 with *some* "stretch"
+`sources.list`... When I booted it in November 2022, the last login
+was from 2017, running the Linux kernel 3.16.0. Incredibly, this OS is
+*still* supported by [Debian LTS](https://wiki.debian.org/LTS), until 2025 for a [limited set of
+packages](https://www.freexian.com/lts/extended/docs/debian-8-support/).
diff --git a/services/dns.mdwn b/services/dns.mdwn
index 41e82d81..68f8b418 100644
--- a/services/dns.mdwn
+++ b/services/dns.mdwn
@@ -71,7 +71,7 @@ inspirantes (politiquement ou autre), préférablement des
 femmes. Exemples utilisés:
 
  * [[hardware/angela]] ([Davis](https://en.wikipedia.org/wiki/Angela_Davis))
- * bell ([Hooks](https://en.wikipedia.org/wiki/Bell_hooks))
+ * [[hardware/bell]] ([Hooks](https://en.wikipedia.org/wiki/Bell_hooks))
  * ([Margaret](https://en.wikipedia.org/wiki/Margaret_Atwood)) [[hardware/atwood]]
  * ([Marie](https://en.wikipedia.org/wiki/Marie_Curie)) [[hardware/curie]]
  * ([Richard](https://en.wikipedia.org/wiki/Richard_Dawkins)) dawkins

summarize forktracer debate
diff --git a/services/upgrades/bookworm.md b/services/upgrades/bookworm.md
index df7c2830..76134ad9 100644
--- a/services/upgrades/bookworm.md
+++ b/services/upgrades/bookworm.md
@@ -367,13 +367,26 @@ Debian, but that term is somewhat to narrow, as I also want to
 consider packages that were *never* part of Debian at all.
 
 Weirdly, the release notes suggest *three* different methods to do
-this, in different part of the documentation. (Filed this as a bug in
-[987017](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987017).)
+this, in different part of the documentation. I filed this as a bug in
+[987017](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987017), but it's still not settled. The previous version of this
+guide (i.e. [[bullseye]]) discussed many alternatives but also did not
+settled on a single one. 
 
-This section tries to figure out the right way forward. See also [step
-4.2.2](https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html#removing-non-debian-packages), [4.8](https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html#obsolete) and [this forum](https://askubuntu.com/questions/98223/how-do-i-get-a-list-of-obsolete-packages).
+The bug report seems to settle to running this *before* the upgrade,
+to see which packages are from backports or weird third-party repos,
+with:
 
-TODO: decide which procedure, look at bullseye.
+    apt list '?narrow(?installed, ?not(?origin(Debian)))'
+
+... which is *roughly* equivalent to `apt-forktracer`, but with less
+details (e.g. it doesn't show the version in the repo).
+
+Then, after the upgrade, we list obsolete packages, which are not
+managed by Debian anymore:
+
+    apt list '~obsolete'
+
+TODO: update above procedure
 
 # References
 

fix the links that i can
minnowboard is still giving a 403 here but that's their fault.
diff --git a/hardware/server/marcos.mdwn b/hardware/server/marcos.mdwn
index c3f691c0..6fe8d158 100644
--- a/hardware/server/marcos.mdwn
+++ b/hardware/server/marcos.mdwn
@@ -393,7 +393,7 @@ requirements (8+GB):
  * [Olimex](https://www.olimex.com/), allwinner-based, 2GB max
  * [Minnowboard](https://minnowboard.org/minnowboard-turbot/technical-specs), Intel Atom based, 2GB max
  * [Espressobin](https://espressobin.net/), Marvell ARM Cortex A53, 2GB max
- * [Banana PI](http://www.banana-pi.org/index.html), IMX6 or MediaTek ARM, 1GB max
+ * [Banana PI](http://www.banana-pi.org/), IMX6 or MediaTek ARM, 1GB max
  * [PC Engines](https://pcengines.ch/apu2.htm), AMD, 4GB max
  * [ODROID](https://www.hardkernel.com/), Intel and ARM, cheap and powerful, 2.5admins.com
    suggest the [Odroid H3](https://www.hardkernel.com/shop/odroid-h3-plus/) which can pack a good punch with little
@@ -407,7 +407,7 @@ interesting for a SAN if I ever upgrade the network to
 10G. 269$-369$. That said, someone on IRC had a very bad experience
 with it: the capacitors were broken and they refused to take it back.
 
-The [Beelink](http://www.bee-link.com/Beelink-MiniPC-TV-BOX-65-1.html) is also interesting: Intel N3450 4GB DDR, 64GB SSD.
+The [Beelink](https://www.bee-link.com/) is also interesting: Intel N3450 4GB DDR, 64GB SSD.
 
 The [Fitlet 2](https://fit-iot.com/web/products/fitlet2/) runs Debian by default and looks like a nice small
 machine.

a new host
diff --git a/hardware/fumiko.md b/hardware/fumiko.md
new file mode 100644
index 00000000..f2aab090
--- /dev/null
+++ b/hardware/fumiko.md
@@ -0,0 +1,40 @@
+[[!toc levels=2]]
+
+fumiko is named after [Fumiko Kaneko](https://en.wikipedia.org/wiki/Fumiko_Kaneko), a Japanese feminist,
+anti-colonialist, anarchist and nihilist, (possibly self-)convicted of
+plotting to assassinate the Japanese emperor.
+
+It's my first "cloud" VM (hence nihilism) designed to survive majour
+outages or moves on [[hardware/server/marcos]].
+
+I picked [linode](https://linode.com/) because it's cheap, it's not Hetzner (which we
+use extensively at work), and they have locations close to me. At
+first I thought of using their [Toronto PoP](https://speedtest.toronto1.linode.com/) but the [Newark
+PoP](https://speedtest.newark.linode.com/) was 10 ms closer (40ms vs 30ms).
+
+I set it up with a plain Debian 11 bullseye install from Linode, then
+installed `git tmux puppet`.
+
+At first I upgraded the box to bookworm, but destroyed the VM and
+recreated it because puppet-agent 7 can't bootstrap against a
+puppet-server 5.
+
+So, bootstrap code is basically:
+
+    apt install foot-terminfo tmux
+    tmux
+    apt upgrade
+    hostname fumiko
+    hostname > /etc/hostname
+    echo 45.33.74.92 fumiko.anarc.at fumiko >> /etc/hosts
+    apt install puppet
+    puppet agent  --test --server puppet.anarc.at
+
+then on the master:
+
+    puppet ca list | grep $HASH_FROM_ABOVE
+    puppet ca sign fumiko.anarc.at
+
+then on fumiko again:
+
+    puppet agent --test
diff --git a/services/dns.mdwn b/services/dns.mdwn
index c9a2c13f..41e82d81 100644
--- a/services/dns.mdwn
+++ b/services/dns.mdwn
@@ -83,6 +83,7 @@ femmes. Exemples utilisés:
  * [[hardware/server/mafalda]] ([yes, the character](https://en.wikipedia.org/wiki/Mafalda))
  * [[hardware/server/plastik]] (a "piece of plastic")
  * ([Harriet](https://en.wikipedia.org/wiki/Harriet_Tubman)) [[hardware/tubman]]
+ * [[hardware/fumiko]] ([Fumiko Kaneko](https://en.wikipedia.org/wiki/Fumiko_Kaneko))
 
 Anciens
 -------
@@ -111,9 +112,6 @@ Les noms suivants pourraient être utilisés pour de futures machines:
  * [Margaret Hamilton][] - developed the on-board flight software for NASA's Apollo program
  * [Ada Lovelace](https://en.wikipedia.org/wiki/Ada_Lovelace) - first programmer
  * [Grace Hopper](https://en.wikipedia.org/wiki/Grace_Hopper) - inventor of the compiler and linker
- * [Fumiko Kaneko](https://en.wikipedia.org/wiki/Fumiko_Kaneko) - Japanese feminist, anti-colonialist, anarchist
-   and nihilist, (possibly self-)convicted of plotting to assassinate
-   the Japanese emperor
  * [Louise Michel](https://fr.wikipedia.org/wiki/Louise_Michel) - anarchiste de la commune de Paris, première à
    arborer le drapeau noir
  * [Séverine](https://fr.wikipedia.org/wiki/S%C3%A9verine) - journaliste, féministe, première femme à diriger un

mention the odroid h3
diff --git a/hardware/server/marcos.mdwn b/hardware/server/marcos.mdwn
index 64b64b79..c3f691c0 100644
--- a/hardware/server/marcos.mdwn
+++ b/hardware/server/marcos.mdwn
@@ -395,7 +395,9 @@ requirements (8+GB):
  * [Espressobin](https://espressobin.net/), Marvell ARM Cortex A53, 2GB max
  * [Banana PI](http://www.banana-pi.org/index.html), IMX6 or MediaTek ARM, 1GB max
  * [PC Engines](https://pcengines.ch/apu2.htm), AMD, 4GB max
- * [ODROID](https://www.hardkernel.com/), Intel and ARM, cheap and powerful
+ * [ODROID](https://www.hardkernel.com/), Intel and ARM, cheap and powerful, 2.5admins.com
+   suggest the [Odroid H3](https://www.hardkernel.com/shop/odroid-h3-plus/) which can pack a good punch with little
+   power usage (but Intel)
  * [Macchiatobin](https://macchiatobin.net/product/macchiatobin-single-shot/)...
 
 The [Macchiatobin](https://macchiatobin.net/product/macchiatobin-single-shot/) is interesting because it has a DDR4 socket so

podman note
diff --git a/services/upgrades/bookworm.md b/services/upgrades/bookworm.md
index 8df28f00..df7c2830 100644
--- a/services/upgrades/bookworm.md
+++ b/services/upgrades/bookworm.md
@@ -166,7 +166,10 @@ can log back in over a serial console or virtual terminal.
 Here are some packages with notable version changes that I
 noticed.
 
-TODO
+ * podman is getting close to usable TODO: update when/if 4.x hits
+   bookworm, as this unleashes GitLab runner support and rootless
+   containers ([bug 1007022](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007022)), right now I need to use the
+   experimental packages
 
 See also the [wiki page about bookworm](https://wiki.debian.org/NewInBookworm) for another list.
 
@@ -223,7 +226,6 @@ TODO
 
 See also the [noteworthy obsolete packages](https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#noteworthy-obsolete-packages) list.
 
-## Security updates URL changes
 # Issues
 
 See also the official list of [known issues](https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html).

more hardware updates
diff --git a/hardware/curie.mdwn b/hardware/curie.mdwn
index 1873ff7f..b3678235 100644
--- a/hardware/curie.mdwn
+++ b/hardware/curie.mdwn
@@ -191,6 +191,8 @@ To investigate: see the [Brix](https://www.gigabyte.com/us/Mini-PcBarebone) and
 
 AMD thingies. Promising, but no sd-card reader. Possibly not a deal breaker.
 
+[very negative review](https://news.ycombinator.com/item?id=33645148)
+
 ### Purism
 
 Purism [announced their own mini-PC as well](https://puri.sm/posts/announcing-the-purism-librem-mini/), although I kind of
diff --git a/hardware/laptop.mdwn b/hardware/laptop.mdwn
index 49eeb722..5568a380 100644
--- a/hardware/laptop.mdwn
+++ b/hardware/laptop.mdwn
@@ -192,6 +192,9 @@ like a nice cheap AMD laptop.
 I like that it has many USB ports and a real ethernet port, even
 though it's slim and light...
 
+See also the [[hardware/curie]] page for this, in particular this
+[very negative review of a Tuxedo](https://news.ycombinator.com/item?id=33645148).
+
 ## Novena
 
 The [Novena](https://en.wikipedia.org/wiki/Novena_(computing_platform)) laptop board is still [on sale](https://www.crowdsupply.com/sutajio-kosagi/novena) but it's showing
diff --git a/hardware/server/marcos.mdwn b/hardware/server/marcos.mdwn
index 2b0901e5..64b64b79 100644
--- a/hardware/server/marcos.mdwn
+++ b/hardware/server/marcos.mdwn
@@ -246,7 +246,7 @@ The Gnubee's hardware also seems to be lacking by modern standards
 now: the CPU is slow and might have trouble maxing out all drives in
 the cluster, as 6 drives going full spin will generate a lot of I/O.
 
-## Helios
+## Helios (dead)
 
 <https://kobol.io/helios4/>
 
@@ -255,6 +255,8 @@ things).
 
 Reviews: [hardware](https://hya.sk/blog/posts/helios64-hardware/), [software](https://hya.sk/blog/posts/helios64-software/).
 
+Update: they [shut down the shop](https://blog.kobol.io/2021/08/25/we-are-pulling-the-plug/).
+
 ## Supermicro
 
 Supermicro sells cases as well as motherboards, and some of those

d'autres nouvelles
diff --git a/blog/2022-09-25-pourquoi-nationaliser.md b/blog/2022-09-25-pourquoi-nationaliser.md
index cb869fb4..f4282bb4 100644
--- a/blog/2022-09-25-pourquoi-nationaliser.md
+++ b/blog/2022-09-25-pourquoi-nationaliser.md
@@ -169,6 +169,8 @@ grand-chose à la maison.
 
 > Cet article a été [[refusé au Devoir|tag/ledevoir-rejet]].
 
+## Nationalisé par la CAQ??
+
 La CAQ, après l'élection de 2022, a commencé à faire du bruit pour
 financer le développement d'un réseau similaire à ce qui est proposé
 ici, sans bien sûr porter attribution de cette idée à moi ou Québec
@@ -182,4 +184,14 @@ privée, mais on ne sait jamais, je pourrais être agréablement
 surpris. En attendant, même si [Ebox offre maintenant la fibre de
 Bell](https://www.dslreports.com/forum/r33497645-Nouveaut-FTTH-chez-EBOX), je n'y ai [toujours pas droit à Montréal](https://www.dslreports.com/forum/r33525932-).
 
+## Pas de service
+
+Finalement, l'idée de passer par Musk et Starlink? ça marche pas si
+bien, en fin de compte... Plusieurs communautés se plaignent de
+[retards et ratés](https://www.lapresse.ca/actualites/regional/2022-11-10/internet-haute-vitesse-en-region/des-retards-et-des-rates.php) selon la Presse. Dans cet article on apprend
+aussi que la subvention provinciale pour Starlink dure seulement deux
+ans, date après laquelle les clients sont censés payer le prix complet
+par eux-mêmes... Un bon moyen, finalement, de financer le
+développement de la clientèle de ce milliardaire!
+
 [[!tag analyse bell histoire "network neutrality" internet politique canada québec ledevoir-rejet]]

sway alternatives
this is mostly from arewewaylandyet.com, but i started it because i
just found out about hyprland, which entered debian backports, and
that looks awesome.
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 061863ad..954bc0f3 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -177,6 +177,15 @@ actually a lot) were *all* **Wayland-specific** changes, not
 
 See a copy of my full [[sway/config|config]] for details.
 
+Other options include:
+
+ * [dwl](https://github.com/djpohly/dwl): tiling, minimalist, dwm for Wayland, not in Debian
+ * [Hyprland](https://hyprland.org/): tiling, fancy animations, not in Debian
+ * [Qtile](https://www.qtile.org/): tiling, extensible, in Python, not in Debian ([1015267](https://bugs.debian.org/1015267))
+ * [river](https://github.com/riverwm/river): Zig, stackable, tagging, not in Debian  ([1006593](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006593))
+ * [velox](https://github.com/michaelforney/velox): inspired by xmonad and dwm, not in Debian
+ * [vivarium](https://github.com/inclement/vivarium): inspired by xmonad, not in Debian
+
 [Sway]: http://swaywm.org/
 [i3 window manager]: https://i3wm.org/
 [Michael Stapelberg]: https://michael.stapelberg.ch/

sent a patch to foot
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index d351ed31..061863ad 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -533,6 +533,17 @@ problems with foot, or any other terminal than xterm, for that matter.
 
 The [foot wiki][] has good troubleshooting instructions as well.
 
+Update: I did find one tiny thing to improve with foot, and it's the
+default logging level which I found pretty verbose. After discussing
+it with the maintainer on IRC, I submitted [this patch](https://codeberg.org/dnkl/foot/pulls/1215) to tweak
+it, which I described like this [on Mastodon](https://kolektiva.social/@Anarcat/109365724789181240):
+
+> today's reason why i will go to hell when i die (TRWIWGTHWID?): a
+> 600-word, 63 lines commit log for a one line change:
+> https://codeberg.org/dnkl/foot/pulls/1215
+
+It's Friday.
+
 [two]: https://anarc.at/blog/2018-04-12-terminal-emulators-1/
 [articles]: https://anarc.at/blog/2018-05-04-terminal-emulators-2/
 [vimperator]: https://en.wikipedia.org/wiki/Vimperator

response
diff --git a/blog/2022-11-17-zfs-migration/comment_2_267f301263df56ecfcb1b18d9b82c755._comment b/blog/2022-11-17-zfs-migration/comment_2_267f301263df56ecfcb1b18d9b82c755._comment
new file mode 100644
index 00000000..631b83a6
--- /dev/null
+++ b/blog/2022-11-17-zfs-migration/comment_2_267f301263df56ecfcb1b18d9b82c755._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""comment 2"""
+ date="2022-11-18T15:41:55Z"
+ content="""
+It's really too bad the sound is so garbled in that presentation...
+
+Are the slides of this available anywhere?
+"""]]

response, thanks everyone!
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 0addda17..d351ed31 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -588,7 +588,8 @@ does that through the `input-method-unstable-v2` protocol ([sample
 emoji picker][], but is not packaged in Debian.
 
 As it turns out, [wtype][] just works as expected, and fixing this was
-basically a [two-line patch][].
+basically a [two-line patch][]. Another alternative, not in Debian, is
+[wofi-pass][].
 
 The other problem is that I actually heavily modified rofi. I use
 "modis" which are not actually implemented in wofi *or* tofi, so I'm
@@ -634,6 +635,7 @@ Note that [wlogout][] could be a partial replacement (just for the
 [ydotool]: https://github.com/ReimuNotMoe/ydotool
 [two-line patch]: https://gitlab.com/anarcat/scripts/-/commit/3e8925e7f4257b44eb527bf7cb8f6d8687e9ed3b
 [wlogout]: https://github.com/ArtsyMacaw/wlogout
+[wofi-pass]: https://github.com/TinfoilSubmarine/wofi-pass
 
 ## Image viewers: geeqie → ?
 
@@ -1297,9 +1299,12 @@ X11 in the end.
 ## Sound/brightness changes notifications
 
 TODO: [Avizo][] can display a pop-up to give feedback on volume and
-brightness changes. Not in Debian.
+brightness changes. Not in Debian. Other alternatives include
+[SwayOSD][] and [sway-nc][], also not in Debian.
 
 [Avizo]: https://github.com/misterdanb/avizo
+[SwayOSD]: https://github.com/ErikReider/SwayOSD
+[sway-nc]: https://github.com/ErikReider/SwayNotificationCenter
 
 # Debugging tricks
 
diff --git a/software/desktop/wayland/comment_1_27a37d038723ab36edb3b0fb1d71a0ad._comment b/software/desktop/wayland/comment_1_27a37d038723ab36edb3b0fb1d71a0ad._comment
index 6e26c8d4..3caa72af 100644
--- a/software/desktop/wayland/comment_1_27a37d038723ab36edb3b0fb1d71a0ad._comment
+++ b/software/desktop/wayland/comment_1_27a37d038723ab36edb3b0fb1d71a0ad._comment
@@ -5,5 +5,5 @@
  subject="pass"
  date="2022-11-18T07:22:37Z"
  content="""
-For pass I use the shell script wofi-pass: https://github.com/TinfoilSubmarine/wofi-pass (unfortunately not packaged for Debian).
+For pass I use the shell script [wofi-pass](https://github.com/TinfoilSubmarine/wofi-pass) (unfortunately not packaged for Debian).
 """]]
diff --git a/software/desktop/wayland/comment_5_394df1a5696812facee5426384641118._comment b/software/desktop/wayland/comment_5_394df1a5696812facee5426384641118._comment
new file mode 100644
index 00000000..7f8c0e54
--- /dev/null
+++ b/software/desktop/wayland/comment_5_394df1a5696812facee5426384641118._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""responses"""
+ date="2022-11-18T15:33:52Z"
+ content="""
+Whoa, lots of comments, thanks everyone! A few responses:
+
+> Check out sway [osd](https://github.com/ErikReider/SwayOSD) and [sway-nc](https://github.com/ErikReider/SwayNotificationCenter) by Erik Reider.
+
+Neither of those are in Debian, but I added those to the article.
+
+> For pass I use the shell script [wofi-pass](https://github.com/TinfoilSubmarine/wofi-pass) (unfortunately not packaged for Debian).
+
+Same, added to the article. Note that with my hack, I can *generally* use rofi for passwords right now... 
+
+> I am using wofi and was not aware that it's not actively maintained in Debian. :(
+
+The problem is actually not in Debian. Maybe I'm mistaken, but the [wofi home page](https://hg.sr.ht/~scoopta/wofi) currently says:
+
+> This project is not being actively maintained. I currently do not have the time nor energy to continue working on it
+
+So I'm not sure it's a good idea to keep pushing it in Debian?
+
+Time will tell, I guess...
+"""]]

approve comment
diff --git a/blog/2022-11-17-zfs-migration/comment_1_3497ed1e542eb68770c93150900b8f40._comment b/blog/2022-11-17-zfs-migration/comment_1_3497ed1e542eb68770c93150900b8f40._comment
new file mode 100644
index 00000000..541521f8
--- /dev/null
+++ b/blog/2022-11-17-zfs-migration/comment_1_3497ed1e542eb68770c93150900b8f40._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ ip="88.196.217.58"
+ claimedauthor="Arti"
+ subject="ZFS on NVMe"
+ date="2022-11-17T13:41:12Z"
+ content="""
+Allan Jude (OpenZFS Developer) recently gave a talk on EuroBSDcon 2022 why ZFS is slow on NVMe
+
+https://www.youtube.com/watch?v=v8sl8gj9UnA
+"""]]
diff --git a/software/desktop/wayland/comment_1_10e14375758c0c5d5f41533c5d1e6ec2._comment b/software/desktop/wayland/comment_1_10e14375758c0c5d5f41533c5d1e6ec2._comment
new file mode 100644
index 00000000..b2140d54
--- /dev/null
+++ b/software/desktop/wayland/comment_1_10e14375758c0c5d5f41533c5d1e6ec2._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="84.187.14.249"
+ claimedauthor="boaznmahne"
+ subject="RE: wayland"
+ date="2022-11-17T16:25:34Z"
+ content="""
+Check out sway [osd](https://github.com/ErikReider/SwayOSD) and [sway-nc](https://github.com/ErikReider/SwayNotificationCenter) by Erik Reider.
+
+"""]]
diff --git a/software/desktop/wayland/comment_1_27a37d038723ab36edb3b0fb1d71a0ad._comment b/software/desktop/wayland/comment_1_27a37d038723ab36edb3b0fb1d71a0ad._comment
new file mode 100644
index 00000000..6e26c8d4
--- /dev/null
+++ b/software/desktop/wayland/comment_1_27a37d038723ab36edb3b0fb1d71a0ad._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ ip="147.161.164.207"
+ claimedauthor="Martin"
+ url="blog.mdosch.de"
+ subject="pass"
+ date="2022-11-18T07:22:37Z"
+ content="""
+For pass I use the shell script wofi-pass: https://github.com/TinfoilSubmarine/wofi-pass (unfortunately not packaged for Debian).
+"""]]
diff --git a/software/desktop/wayland/comment_1_6356c7a3e41140a2e103beb3e426989c._comment b/software/desktop/wayland/comment_1_6356c7a3e41140a2e103beb3e426989c._comment
new file mode 100644
index 00000000..c1c15e96
--- /dev/null
+++ b/software/desktop/wayland/comment_1_6356c7a3e41140a2e103beb3e426989c._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ ip="147.161.164.207"
+ claimedauthor="Martin"
+ url="blog.mdosch.de"
+ subject="wofi"
+ date="2022-11-18T07:18:53Z"
+ content="""
+> Wofi	yes	dmenu/drun replacement, not actively maintained
+
+I am using wofi and was not aware that it's not actively maintained in Debian. :(
+Yesterday I pulled the repo from salsa und updated wofi to 1.3 and was able to build it (with adding a workaround for a ccache problem to d/rules). I sent an email to the maintainers asking whether they are OK with me pushing the update to salsa and uploading it to mentors.debian.org.
+Let's see what they say. If I don't hear a veto within one week I might just go ahead.
+"""]]
diff --git a/software/desktop/wayland/comment_1_d84364cc5d6a9ae7ec5678aad4a25c06._comment b/software/desktop/wayland/comment_1_d84364cc5d6a9ae7ec5678aad4a25c06._comment
new file mode 100644
index 00000000..63d16f42
--- /dev/null
+++ b/software/desktop/wayland/comment_1_d84364cc5d6a9ae7ec5678aad4a25c06._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ ip="45.80.168.93"
+ claimedauthor="kcinimod"
+ subject="comment 1"
+ date="2022-11-17T19:33:31Z"
+ content="""
+Nice read. I am worried about the watered down security model as well. The \"wob\" package in Debian can be used to for Brightness/Volume \"status\". It is a bit slow though. I use \"greetd\" for display manager (it is also in Debian) but currently \"wlgreet\" is not packaged. There is a \"Go\" TUI greeter that is pretty neat (it has read-to-use built binaries on Github for easy access). I am not too happy about xdg-desktop-portal-wlr depending on xdg-desktop-portal as last time I tried the latter it was very intrusive (3 long running daemon in you session to worry about and only one actually matters for xdg-desktop-portal-wlr AFAIK).
+
+Thanks for the write-up
+"""]]

trim enabled on curie
diff --git a/blog/2022-11-17-zfs-migration.md b/blog/2022-11-17-zfs-migration.md
index 06d3e8de..a4338286 100644
--- a/blog/2022-11-17-zfs-migration.md
+++ b/blog/2022-11-17-zfs-migration.md
@@ -1161,7 +1161,6 @@ SMART self-test succeeded.
   [[software/zfs]] for alternatives to syncoid/sanoid there
 - TODO: setup backup cron job (or timer?)
 - TODO: swap still not setup on curie, see [[software/zfs#swap]]
-- TODO: [TRIM][] on curie
 - TODO: document this somewhere: bpool and rpool are both pools and
   datasets. that's pretty confusing, but also very useful because it
   allows for pool-wide recursive snapshots, which are used for the

mpd failure
diff --git a/services/upgrades/bookworm.md b/services/upgrades/bookworm.md
index 504fd8db..8df28f00 100644
--- a/services/upgrades/bookworm.md
+++ b/services/upgrades/bookworm.md
@@ -265,6 +265,41 @@ want to have installed on my machines:
  * [tty-clock](https://tracker.debian.org/pkg/tty-clock) - [FTBFS](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997179) (wait that's mine!)
  * [xsane]() - unmaintained upstream since 2014 ([bug 1013933](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013933))
 
+### MPD fails to start
+
+This one was hard to diagnose because the normal output does not show
+the *real* error:
+
+    $ mpd --no-daemon 
+    Nov 17 15:16 : server_socket: bind to '0.0.0.0:6600' failed (continuing anyway, because binding to '[::]:6600' succeeded): Failed to bind socket: Address already in use
+    Nov 17 15:16 : exception: Tag list mismatch, discarding database file
+    Abandon
+
+The full error is visible only with `--verbose`:
+
+    anarcat@curie:~$ mpd --no-daemon --stdout --verbose
+    config_file: loading file /home/anarcat/.mpdconf
+    server_socket: bind to '0.0.0.0:6600' failed (continuing anyway, because binding to '[::]:6600' succeeded): Failed to bind socket: Address already in use
+    libsamplerate: libsamplerate converter 'Fastest Sinc Interpolator'
+    vorbis: Xiph.Org libVorbis 1.3.7
+    opus: libopus 1.3.1
+    sndfile: libsndfile-1.1.0
+    hybrid_dsd: The Hybrid DSD decoder is disabled because it was not explicitly enabled
+    adplug: adplug 2.3.3
+    simple_db: reading DB
+    exception: Tag list mismatch, discarding database file
+    curl: version 7.86.0
+    curl: with GnuTLS/3.7.8
+    update: spawned thread for update job id 1
+    state_file: Loading state file /home/anarcat/.mpd/state
+    update: starting
+    terminate called after throwing an instance of 'std::runtime_error'
+      what():  io_uring_get_sqe() failed
+    Abandon
+
+... and this is [bug 1023872](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023872). The workaround is to install
+[liburing2](https://tracker.debian.org/liburing2) from unstable, while we wait for upstream to fix this.
+
 ## Resolved
 
 ### libcrypt disappeared on upgrade

do not assume the user is running as root
we're using sudo elsewhere, if we were not needing sudo, we should
remove it everywhere.
diff --git a/services/upgrades/bookworm.md b/services/upgrades/bookworm.md
index 672e0afb..504fd8db 100644
--- a/services/upgrades/bookworm.md
+++ b/services/upgrades/bookworm.md
@@ -49,12 +49,12 @@ can log back in over a serial console or virtual terminal.
         : reset to the default locale
         export LC_ALL=C.UTF-8 &&
         : put server in maintenance &&
-        touch /etc/nologin &&
+        sudo touch /etc/nologin &&
         : install some dependencies
         sudo apt install ttyrec screen debconf-utils deborphan apt-forktracer &&
         : create ttyrec file with adequate permissions &&
-        touch /var/log/upgrade-bookworm.ttyrec &&
-        chmod 600 /var/log/upgrade-bookworm.ttyrec &&
+        sudo touch /var/log/upgrade-bookworm.ttyrec &&
+        sudo chmod 600 /var/log/upgrade-bookworm.ttyrec &&
         sudo ttyrec -e screen /var/log/upgrade-bookworm.ttyrec
 
  2. Backups and checks:
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index 3bf42dc7..ea2d8c8b 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -47,12 +47,12 @@ connection.
         : reset to the default locale
         export LC_ALL=C.UTF-8 &&
         : put server in maintenance &&
-        touch /etc/nologin &&
+        sudo touch /etc/nologin &&
         : install some dependencies
         sudo apt install ttyrec screen debconf-utils deborphan apt-forktracer &&
         : create ttyrec file with adequate permissions &&
-        touch /var/log/upgrade-bullseye.ttyrec &&
-        chmod 600 /var/log/upgrade-bullseye.ttyrec &&
+        sudo touch /var/log/upgrade-bullseye.ttyrec &&
+        sudo chmod 600 /var/log/upgrade-bullseye.ttyrec &&
         sudo ttyrec -e screen /var/log/upgrade-bullseye.ttyrec
 
  2. Backups and checks:

stop using apt-show-versions, it's purged by puppet
diff --git a/services/upgrades/bookworm.md b/services/upgrades/bookworm.md
index 637d4a74..672e0afb 100644
--- a/services/upgrades/bookworm.md
+++ b/services/upgrades/bookworm.md
@@ -51,7 +51,7 @@ can log back in over a serial console or virtual terminal.
         : put server in maintenance &&
         touch /etc/nologin &&
         : install some dependencies
-        sudo apt install ttyrec screen debconf-utils apt-show-versions deborphan apt-forktracer &&
+        sudo apt install ttyrec screen debconf-utils deborphan apt-forktracer &&
         : create ttyrec file with adequate permissions &&
         touch /var/log/upgrade-bookworm.ttyrec &&
         chmod 600 /var/log/upgrade-bookworm.ttyrec &&
diff --git a/services/upgrades/bullseye.mdwn b/services/upgrades/bullseye.mdwn
index bba67750..3bf42dc7 100644
--- a/services/upgrades/bullseye.mdwn
+++ b/services/upgrades/bullseye.mdwn
@@ -49,7 +49,7 @@ connection.
         : put server in maintenance &&
         touch /etc/nologin &&
         : install some dependencies
-        sudo apt install ttyrec screen debconf-utils apt-show-versions deborphan apt-forktracer &&
+        sudo apt install ttyrec screen debconf-utils deborphan apt-forktracer &&
         : create ttyrec file with adequate permissions &&
         touch /var/log/upgrade-bullseye.ttyrec &&
         chmod 600 /var/log/upgrade-bullseye.ttyrec &&

pubpaste in Debian, properly install rsendmail
diff --git a/services/upgrades/bookworm.md b/services/upgrades/bookworm.md
index 9618cbd9..637d4a74 100644
--- a/services/upgrades/bookworm.md
+++ b/services/upgrades/bookworm.md
@@ -132,8 +132,8 @@ can log back in over a serial console or virtual terminal.
         read -r _ &&
         (puppet agent -t || true) &&
         : reinstall Python packages to follow Python upgrade &&
-        for package in rsendmail pubpaste ; do
-            cd ~/src/$package && pip3 install .
+        for package in rsendmail ; do
+            cd ~anarcat/src/$package && pip3 install . || echo WARNING: failed to install $package
         done &&
         : rm -f /etc/apt/apt.conf.d/50unattended-upgrades.dpkg-dist /etc/ca-certificates.conf.dpkg-old /etc/cron.daily/bsdmainutils.dpkg-remove /etc/default/prometheus-apache-exporter.dpkg-dist /etc/default/prometheus-node-exporter.dpkg-dist /etc/logrotate.d/apache2.dpkg-dist /etc/nagios/nrpe.cfg.dpkg-dist /etc/ssh/ssh_config.dpkg-dist /etc/ssh/sshd_config.ucf-dist /etc/unbound/unbound.conf.dpkg-dist &&
         printf "\a" &&

a bunch of packages are back in bookworm
diff --git a/services/upgrades/bookworm.md b/services/upgrades/bookworm.md
index 67612032..9618cbd9 100644
--- a/services/upgrades/bookworm.md
+++ b/services/upgrades/bookworm.md
@@ -256,25 +256,14 @@ At the time of this writing (long before the freeze), there's a
 significant number of packages gone from bookworm, which I actually
 want to have installed on my machines:
 
- * [anki](https://tracker.debian.org/anki) - too old, buggy ([bug 958853](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958853))
- * [audacity](https://tracker.debian.org/pkg/audacity) - [FTBFS with latest ffmpeg](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004598), fixed upstream
- * [emacs-lsp-ui](https://tracker.debian.org/pkg/emacs-lsp-ui), blocked on [flycheck](https://tracker.debian.org/pkg/flycheck), itself blocked on
-   [haskell-mode](https://tracker.debian.org/pkg/haskell-mode), itself on [haskell-stack](https://tracker.debian.org/pkg/haskell-stack), itself on [bug
-   1011855](https://bugs.debian.org/1011855)
- * [chirp](https://tracker.debian.org/chirp), removed from testing because of a bug ([bug
-   1012538](https://bugs.debian.org/1012538)), likely caused by the Python 3 transition ([bug
-   983721]( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983721)) - it basically needs a rewrite of the GUI because pygtk
-   is dead as well :(
- * [git-annex](https://tracker.debian.org/git-annex), [hledger](https://tracker.debian.org/hledger), [hopenpgp-tools](https://tracker.debian.org/hopenpgp-tools), all blocked
-   because haskell is currently broken un Debian
  * [git-sizer](https://tracker.debian.org/pkg/git-sizer) - [regression on ppc64el](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009690), [FTBFS on ppc64el](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010541)
    (?!)
- * [mumble](https://tracker.debian.org/pkg/mumble) - [FTBFS with OpenSSL 3.0](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005719), fixed upstream
- * [onionshare](https://tracker.debian.org/pkg/onionshare) - [FTBFS](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997499), [insecure](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014966), needs an update from
-   upstream
+ * [github-backup](https://tracker.debian.org/pkg/github-backup) - [FTBFS with missing dep](https://bugs.debian.org/1017298)
+ * [golint](https://tracker.debian.org/pkg/golint) - [discontinued upstream](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016427)
+ * [hopenpgp-tools](https://tracker.debian.org/hopenpgp-tools) - CI regression on armel
+ * [magit](https://tracker.debian.org/magit), [magit-todos](https://tracker.debian.org/magit-todos) - [FTBFS](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020153)
  * [tty-clock](https://tracker.debian.org/pkg/tty-clock) - [FTBFS](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997179) (wait that's mine!)
  * [xsane]() - unmaintained upstream since 2014 ([bug 1013933](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013933))
- * [yubikey-manager](https://tracker.debian.org/pkg/yubikey-manager) - [some policy failure](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012587)
 
 ## Resolved
 
@@ -294,10 +283,29 @@ remember it all but it was scary and hairy.
 
 ### Packages to remove from my configuration
 
+ * [anki](https://tracker.debian.org/anki) - too old, buggy ([bug 958853](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958853)), unused
  * [python3-lsp-flake8](https://tracker.debian.org/pkg/python-lsp-flake8): was deliberately removed from Debian as
    the functionality is already present in `python-lsp-server`, see
    [bug 1009941](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009941)
 
+### Packages restored
+
+Those packages were removed from bookworm and eventually restored.
+
+ * [audacity](https://tracker.debian.org/pkg/audacity) - [FTBFS with latest ffmpeg](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004598), fixed upstream
+ * [chirp](https://tracker.debian.org/chirp), removed from testing because of a bug ([bug
+   1012538](https://bugs.debian.org/1012538)), likely caused by the Python 3 transition ([bug
+   983721]( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983721)) - it basically needs a rewrite of the GUI because pygtk
+   is dead as well :(
+ * [emacs-lsp-ui](https://tracker.debian.org/pkg/emacs-lsp-ui), blocked on [flycheck](https://tracker.debian.org/pkg/flycheck), itself blocked on
+   [haskell-mode](https://tracker.debian.org/pkg/haskell-mode), itself on [haskell-stack](https://tracker.debian.org/pkg/haskell-stack), itself on [bug
+   1011855](https://bugs.debian.org/1011855)
+ * [git-annex](https://tracker.debian.org/git-annex), and [hledger](https://tracker.debian.org/hledger) were blocked because Haskell had
+   serious breakage in Debian, fixed!
+ * [mumble](https://tracker.debian.org/pkg/mumble) - [FTBFS with OpenSSL 3.0](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005719), fixed upstream
+ * [onionshare](https://tracker.debian.org/pkg/onionshare) - [FTBFS](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997499), [insecure](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014966), fixed upstream
+ * [yubikey-manager](https://tracker.debian.org/pkg/yubikey-manager) - [some policy failure](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012587), fixed
+
 # Troubleshooting
 
 ## Upgrade failures

zfs bug in bookworm upgrade
diff --git a/services/upgrades/bookworm.md b/services/upgrades/bookworm.md
index 47a3ea89..67612032 100644
--- a/services/upgrades/bookworm.md
+++ b/services/upgrades/bookworm.md
@@ -230,6 +230,26 @@ See also the official list of [known issues](https://www.debian.org/releases/boo
 
 ## Pending
 
+### ZFS upgrade failure
+
+The `zfs-dkms` package has this weird bug where it tries to configure
+the *old* package:
+
+    Setting up linux-image-6.0.0-4-amd64 (6.0.8-1) ...
+    /etc/kernel/postinst.d/dkms:
+    dkms: running auto installation service for kernel 6.0.0-4-amd64:Error! Could not locate dkms.conf file.
+    File: /var/lib/dkms/zfs/2.0.3/source/dkms.conf does not exist.
+     failed!
+    run-parts: /etc/kernel/postinst.d/dkms exited with return code 4
+    dpkg: error processing package linux-image-6.0.0-4-amd64 (--configure):
+     installed linux-image-6.0.0-4-amd64 package post-installation script subprocess returned error exit status 1
+
+The workaround:
+
+    rm -rf /var/lib/dkms/2.0.3
+
+This bug was filed as [bug 1024326](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024326) in the Debian package.
+
 ### Packages removed from bookworm
 
 At the time of this writing (long before the freeze), there's a

waybar has proper tray support
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 4a247c3a..0addda17 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -11,15 +11,21 @@ The current status is that I've been able to convert my `i3`
 configuration to Sway, and adapt my `systemd` startup sequence to the
 new environment. Screen sharing only works with Pipewire, so I also
 did that migration, which basically requires an upgrade to Debian
-bookworm to get a nice enough Pipewire release. My biggest irritant
-right now is that the tray icons (e.g. Network Manager) are not
-clickable (!?).
+bookworm to get a nice enough Pipewire release.
 
 I'm testing Wayland on my laptop, but I'm not using it as a daily
-driver because I first need to upgrade to Debian bookworm there.
+driver because I first need to upgrade to Debian bookworm on my main
+workstation.
+
+Most irritants have been solved one way or the other. My main problem
+with Wayland right now is that I spent a frigging week doing the
+conversion: it's exciting and new, but it basically sucked the life
+out of all my other projects and it's distracting, and I want it to
+stop.
 
 The rest of this page documents why I made the switch, how it
-happened, and what's left to do.
+happened, and what's left to do. Hopefully it will keep you from
+spending as much time as I did in fixing this.
 
 TL;DR: Wayland is [mostly ready][arewewaylandyet.com]. Main blockers you might find are
 that you need to do manual configurations, [DisplayLink][] (multiple
@@ -180,13 +186,47 @@ See a copy of my full [[sway/config|config]] for details.
 [lots more documentation]: https://i3wm.org/docs/
 [test suite]: https://github.com/i3/i3/tree/next/testcases
 
-## Status bar: py3status
+## Status bar: py3status → waybar
 
 I have invested quite a bit of effort in setting up my status bar with
-[py3status][]. It supports Sway directly, and did not actually
-require any change when migrating to Wayland. Awesome.
+[py3status][]. It supports Sway directly, and did not actually require
+any change when migrating to Wayland. 
+
+Unfortunately, I had trouble making `nm-applet` work. Based on [this
+nm-applet.service][], I found that you need to pass `--indicator` for
+it to show up at all.
+
+In theory, [tray icon support was merged in 1.5][], but in practice
+there are still [several limitations][], like [icons not
+clickable][]. Also, on startup, `nm-applet --indicator` triggers this
+error in the Sway logs:
+   
+    nov 11 22:34:12 angela sway[298938]: 00:49:42.325 [INFO] [swaybar/tray/host.c:24] Registering Status Notifier Item ':1.47/org/ayatana/NotificationItem/nm_applet'
+    nov 11 22:34:12 angela sway[298938]: 00:49:42.327 [ERROR] [swaybar/tray/item.c:127] :1.47/org/ayatana/NotificationItem/nm_applet IconPixmap: No such property “IconPixmap”
+    nov 11 22:34:12 angela sway[298938]: 00:49:42.327 [ERROR] [swaybar/tray/item.c:127] :1.47/org/ayatana/NotificationItem/nm_applet AttentionIconPixmap: No such property “AttentionIconPixmap”
+    nov 11 22:34:12 angela sway[298938]: 00:49:42.327 [ERROR] [swaybar/tray/item.c:127] :1.47/org/ayatana/NotificationItem/nm_applet ItemIsMenu: No such property “ItemIsMenu”
+    nov 11 22:36:10 angela sway[313419]: info: fcft.c:838: /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf: size=24.00pt/32px, dpi=96.00
+
+... but that seems innocuous. The tray icon displays but is not
+clickable.
+
+Note that there is currently (November 2022) a [pull request][] to
+hook up a "Tray D-Bus Menu" which, [according to Reddit][] might fix
+this, or at least be somewhat relevant.
+
+If you don't see the icon, check the `bar.tray_output` property in the
+Sway config, try: `tray_output *`.
+
+The non-working tray was the biggest irritant in my migration. I have
+used `nmtui` to connect to new Wifi hotspots or change connection
+settings, but that doesn't support actions like "turn off WiFi".
+   
+I eventually fixed this by switching from [py3status][] to
+[waybar][], which was another yak horde shaving session, but
+ultimately, it worked.
 
 [py3status]: https://py3status.readthedocs.io/
+[waybar]: https://github.com/Alexays/Waybar/
 
 ## Web browser: Firefox
 
@@ -448,6 +488,8 @@ Fonts are much crisper than Xterm and Emacs. URLs are not clickable
 but the URL selector (<kbd>control-shift-u</kbd>) is just plain
 awesome (think "[vimperator][]" for the terminal). 
 
+There's [cool hack to jump between prompts](https://codeberg.org/dnkl/foot/wiki#user-content-jumping-between-prompts).
+
 Copy-paste works. True colors work. The word-wrapping is excellent: it
 doesn't lose one byte. Emojis are nicely sized and colored. Font
 resize works. There's even scroll back search
@@ -851,9 +893,12 @@ how many things you were using are tightly bound to X.
    hook up a "Tray D-Bus Menu" which, [according to Reddit][] might
    fix this, or at least be somewhat relevant.
    
-   This is the biggest irritant in my migration. I have to use `nmtui`
-   to connect to new Wifi hotspots or change connection settings, it's
-   pretty bad.
+   This was the biggest irritant in my migration. I have used `nmtui`
+   to connect to new Wifi hotspots or change connection settings, but
+   that doesn't support actions like "turn off WiFi".
+   
+   I eventually fixed this by switching from [py3status][] to
+   [waybar](https://github.com/Alexays/Waybar/).
 
  * window switcher: in `i3` I was using this bespoke [i3-focus][]
    script, which doesn't work under Sway, [swayr][] an option, not in

copy over bookworm procedure
diff --git a/services/upgrades/bookworm.md b/services/upgrades/bookworm.md
index 17a26082..47a3ea89 100644
--- a/services/upgrades/bookworm.md
+++ b/services/upgrades/bookworm.md
@@ -1,12 +1,233 @@
-[[!meta title="Summary update notes for the bookworm upgrade"]]
+[[!meta title="Bookworm upgrade"]]
 
-This is not a full guide yet, I basically followed [[bullseye]] but
-messed up and ended up jumping to bookworm instead. The bug in the
-bullseye procedure has been since then fixed, but it's still worth
-reporting on some of the problems I encountered.
+[[!toc levels=3]]
 
+It's the moost wonderful tiiime of the yeaar! Yes, my friends, it's
+that time again, when the northern hemisphere freezes over and tries
+to make us forget that it might stop doing that soon and kill us
+all...
+
+And yes, it's also the time where Debian starts heading towards a
+freeze, and when, as a dare devil, try to upgrade as many Debian I can
+lay my hands on to bookworm.
+
+This document contains my upgrade procedure, notable changes in the
+new version, issues I have stumbled upon (and possibly fixed), and
+troubleshooting instructions.
+
+It does not hope to replace the official documentation: it is a
+personal, living document that I have started keeping back when I
+upgraded to [[jessie]]. The other documents can be found in the parent
+[[upgrades]] page.
+
+# Procedure
+
+This procedure is designed to be applied, in batch, on multiple
+servers. Do NOT follow this procedure unless you are familiar with the
+command line and the Debian upgrade process. It has been crafted by
+and for experienced system administrators that have dozens if not
+hundreds of servers to upgrade.
+
+In particular, it runs almost completely unattended: configuration
+changes are not prompted during the upgrade, and just not applied at
+all, which *will* break services in many cases. I use a
+[clean-conflicts](https://gitlab.com/anarcat/koumbit-scripts/-/blob/master/vps/clean_conflicts) script to do this all in one shot to shorten the
+upgrade process (without it, configuration file changes stop the
+upgrade at more or less random times). Then those changes get applied
+after a reboot. And yes, that's even more dangerous.
+
+IMPORTANT: if you are doing this procedure over SSH (I had the
+privilege of having a console), you may want to [upgrade SSH first](https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#ssh-not-available)
+as it has a longer downtime period, especially if you are on a flaky
+connection.
+
+This procedure *will* kill your graphical session, so make sure you
+can log back in over a serial console or virtual terminal.
+
+ 1. Preparation:
+
+        : reset to the default locale
+        export LC_ALL=C.UTF-8 &&
+        : put server in maintenance &&
+        touch /etc/nologin &&
+        : install some dependencies
+        sudo apt install ttyrec screen debconf-utils apt-show-versions deborphan apt-forktracer &&
+        : create ttyrec file with adequate permissions &&
+        touch /var/log/upgrade-bookworm.ttyrec &&
+        chmod 600 /var/log/upgrade-bookworm.ttyrec &&
+        sudo ttyrec -e screen /var/log/upgrade-bookworm.ttyrec
+
+ 2. Backups and checks:
+
+        ( 
+          umask 0077 &&
+          tar cfz /var/backups/pre-bookworm-backup.tgz /etc /var/lib/dpkg /var/lib/apt/extended_states /var/cache/debconf $( [ -e /var/lib/aptitude/pkgstates ] && echo /var/lib/aptitude/pkgstates ) &&
+          dpkg --get-selections "*" > /var/backups/dpkg-selections-pre-bookworm.txt &&
+          debconf-get-selections > /var/backups/debconf-selections-pre-bookworm.txt
+        ) &&
+        ( puppet agent --test || true )&&
+        apt-mark showhold &&
+        dpkg --audit &&
+        : look for dkms packages and make sure they are relevant, if not, purge. &&
+        ( dpkg -l '*dkms' || true ) &&
+        : look for leftover config files &&
+        /home/anarcat/src/koumbit-scripts/vps/clean_conflicts &&
+        : run backups &&
+        /home/anarcat/bin/backup-$(hostname) &&
+        printf "End of Step 2\a\n"
+
+ 3. Perform any pending upgrade and clear out old pins:
+
+        puppet agent --disable "running major upgrade" &&
+        apt update && apt -y upgrade &&
+        : Check for pinned, on hold, packages, and possibly disable &&
+        rm -f /etc/apt/preferences /etc/apt/preferences.d/* &&
+        rm -f /etc/apt/sources.list.d/backports.debian.org.list &&
+        rm -f /etc/apt/sources.list.d/backports.list &&
+        rm -f /etc/apt/sources.list.d/bookworm.list &&
+        rm -f /etc/apt/sources.list.d/bullseye.list &&
+        rm -f /etc/apt/sources.list.d/buster-backports.list &&
+        rm -f /etc/apt/sources.list.d/experimental.list &&
+        rm -f /etc/apt/sources.list.d/incoming.list &&
+        rm -f /etc/apt/sources.list.d/proposed-updates.list &&
+        rm -f /etc/apt/sources.list.d/sid.list &&
+        rm -f /etc/apt/sources.list.d/testing.list &&
+        : purge removed packages &&
+        apt purge $(dpkg -l | awk '/^rc/ { print $2 }') &&
+        apt autoremove -y --purge &&
+        : possibly clean up old kernels &&
+        dpkg -l 'linux-image-*' &&
+        : look for packages from backports, other suites or archives &&
+        : if possible, switch to official packages by disabling third-party repositories &&
+        apt-forktracer | sort &&
+        printf "End of Step 3\a\n"
+
+ 4. Check free space, see [this guide to free up space][] and
+    download packages:
+
+        systemctl stop apt-daily.timer &&
+        sed -i 's#bullseye-security#bookworm-security#' $(ls /etc/apt/sources.list /etc/apt/sources.list.d/*) &&
+        sed -i 's/bullseye/bookworm/g' $(ls /etc/apt/sources.list /etc/apt/sources.list.d/*) &&
+        apt update &&
+        apt -y -d full-upgrade &&
+        apt -y -d upgrade &&
+        apt -y -d dist-upgrade &&
+        df -h &&
+        printf "End of Step 4\a\n"
+
+[this guide to free up space]: http://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html#sufficient-space
+
+ 5. Actual upgrade run:
+
+        env DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none APT_LISTBUGS_FRONTEND=none UCF_FORCE_CONFFOLD=y \
+            apt full-upgrade -y -o Dpkg::Options::='--force-confdef' -o Dpkg::Options::='--force-confold' &&
+        printf "End of Step 5\a\n"
+
+ 6. Post-upgrade procedures:
+
+        apt-get update --allow-releaseinfo-change &&
+        puppet agent --enable &&
+        puppet agent -t --noop &&
+        printf "Press enter to continue, Ctrl-C to abort." &&
+        read -r _ &&
+        (puppet agent -t || true) &&
+        : reinstall Python packages to follow Python upgrade &&
+        for package in rsendmail pubpaste ; do
+            cd ~/src/$package && pip3 install .
+        done &&
+        : rm -f /etc/apt/apt.conf.d/50unattended-upgrades.dpkg-dist /etc/ca-certificates.conf.dpkg-old /etc/cron.daily/bsdmainutils.dpkg-remove /etc/default/prometheus-apache-exporter.dpkg-dist /etc/default/prometheus-node-exporter.dpkg-dist /etc/logrotate.d/apache2.dpkg-dist /etc/nagios/nrpe.cfg.dpkg-dist /etc/ssh/ssh_config.dpkg-dist /etc/ssh/sshd_config.ucf-dist /etc/unbound/unbound.conf.dpkg-dist &&
+        printf "\a" &&
+        /home/anarcat/src/koumbit-scripts/vps/clean_conflicts &&
+        systemctl start apt-daily.timer &&
+        printf "End of Step 6\a\n" &&
+        shutdown -r +1 "rebooting to get rid of old kernel image..."
+
+ 7. Post-upgrade checks:
+
+        export LC_ALL=C.UTF-8 &&
+        sudo ttyrec -a -e screen /var/log/upgrade-bookworm.ttyrec
+
+        apt-mark manual bind9-dnsutils
+        apt purge libgcc1:amd64 gcc-8-base:amd64
+        apt purge $(dpkg -l | awk '/^rc/ { print $2 }') # purge removed packages
+        apt autoremove -y --purge
+        apt purge $(deborphan --guess-dummy | grep -v python-is-python2)
+        while deborphan -n | grep -v python-is-python2 | grep -q . ; do apt purge $(deborphan -n | grep -v python-is-python2); done
+        apt autoremove -y --purge
+        apt clean
+        # review and purge older kernel if the new one boots properly
+        dpkg -l 'linux-image*'
+        # review packages that are not in the new distribution
+        apt-forktracer | sort
+        printf "All procedures completed\a\n" &&
+
+# Notable changes
+
+Here are some packages with notable version changes that I
+noticed.
+
+TODO
+
+See also the [wiki page about bookworm](https://wiki.debian.org/NewInBookworm) for another list.
+
+## New packages
+
+This is a curated list of packages that were introduced in
+bookworm. There are actually *thousands* of new packages in the new
+Debian release, but this is a small selection of projects I found
+particularly interesting:
+
+TODO
+
+## My packages
+
+In packages I maintain, those are the important changes:
+
+TODO
+
+## Updated packages
+
+This table summarizes package version changes I find interesting.

(Diff truncated)
clarify conclusion on security, prompted by pabs
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index b2d0167d..4a247c3a 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -1301,28 +1301,33 @@ Wayland just to make things work. Pretty much everywhere we need to,
 we punched a hole in the security model:
 
  * windows can spy on each other (although [xdg-desktop-portal-wlr][]
-   might offer confirmation, optionally?)
- * windows can type over each other (through wtype)
- * windows can overlay on top of each other
-
-I think the only thing that's not possible in Wayland (yet?) is
-one application overwriting another application's display, and even
-there, things like [gammastep][] show you can at least alter the
-display somehow.
-
-[Wikipedia describes the security properties of Wayland][] as it "isolates
-the input and output of every window, achieving confidentiality,
-integrity and availability for both." I'm not sure those of Wayland
-are actually realized in the actual implementation, because of all
-those holes punched in the design.
-
-It does offer a better basis to implement such a system, however, but
-it feels like the Linux applications security model lacks critical
-ideas like the user approving "yes, this application can share my
-screen right now, or always". Applications themselves *might* have
-these kind of dialogs enabled, but it's mostly absent, and that is
+   does confirm if you have some `chooser` installed, see
+   [xdg-desktop-portal-wrl(5)][])
+
+ * windows can type over each other (through e.g. [wtype][] through
+   the [virtual-keyboard protocol](https://wayland.app/protocols/virtual-keyboard-unstable-v1))
+
+ * windows can overlay on top of each other (so one app could, for
+   example, spoof a password dialog, through the [layer-shell
+   protocol](https://wayland.app/protocols/wlr-layer-shell-unstable-v1))
+
+[Wikipedia describes the security properties of Wayland][] as it
+"isolates the input and output of every window, achieving
+confidentiality, integrity and availability for both." I'm not sure
+those are actually realized in the actual implementation, because of
+all those holes punched in the design, at least in Sway. For example,
+apparently the GNOME compositor doesn't have the virtual-keyboard
+protocol, but they do have (another?!) [text input protocol](https://www.phoronix.com/news/GNOME-Wayland-GTK-Input-Proto).
+
+Wayland does offer a better basis to implement such a system,
+however. It feels like the Linux applications security model lacks
+critical decision points in the UI, like the user approving "yes, this
+application can share my screen now". Applications themselves *might*
+have some of those prompts, but it's not mandatory, and that is
 worrisome.
 
 [Wikipedia describes the security properties of Wayland]: https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Comparison_with_other_window_systems
 
 [[!tag unix wayland blog desktop firefox emacs debian debian-planet]]
+
+[xdg-desktop-portal-wrl(5)]: https://manpages.debian.org/xdg-desktop-portal-wlr.5

clarify that you can keep using pulseaudio
suggested by https://floss.social/@be/109357337092439408 thanks!
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index ba6b302e..b2d0167d 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -1149,10 +1149,12 @@ but that's something that's rarely needed.
 ## Pipewire
 
 This is a whole topic onto itself, but migrating to Wayland also
-involves migrating to [Pipewire][] if you want screen sharing to
-work. That migration is actually something I've wanted to do anyways:
-Pipewire's design seems much better than Pulseaudio, as it folds in
-[JACK][] features that allow pretty neat tricks.
+involves using [Pipewire][] if you want screen sharing to work. You
+*can* actually keep using Pulseaudio for audio, that said, but that
+migration is actually something I've wanted to do anyways: Pipewire's
+design seems much better than Pulseaudio, as it folds in [JACK][]
+features which allows for pretty neat tricks. (Which I should probably
+show in a separate post, because this one is getting rather long.)
 
 I first tried this migration in Debian bullseye, and it didn't work
 very well. Ardour would [fail to export tracks][] and I would get
@@ -1164,7 +1166,7 @@ on blabbering on my own for a solid 5 minutes until I realized what
 was going on. By then, people had tried numerous ways of letting me
 know that something was off, including (apparently) coughing, saying
 "hello?", chat messages, IRC, and so on, until they just gave up and
-left. 
+left.
 
 I suspect that was also a Pipewire bug, but it could also have been
 that I muted the tab by error, as I recently learned that clicking on
@@ -1172,8 +1174,9 @@ the little tiny speaker icon on a tab mutes that tab. Since the tab
 itself can get pretty small when you have lots of them, it's actually
 quite frequently that I mistakenly mute tabs.
 
-Anyways. Point is, I already knew how to make the migration, and I had
-[documented how to make the change in Puppet][]. It's basically:
+Anyways. Point is: I already knew how to make the migration, and I had
+already [documented how to make the change in Puppet][]. It's
+basically:
 
     apt install pipewire pipewire-audio-client-libraries pipewire-pulse wireplumber 
 

clarify we're talking about major xorg releases here
... in response to: https://libretooth.gr/@xinomilo/109358381687170146
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index c01a7fd6..ba6b302e 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -72,11 +72,11 @@ worth a read as well][artemis].
 The point here is not to bash one side or the other, or even do a
 thorough comparison. I start with the premise that Xorg is likely
 going away in the future and that I will need to adapt some day. In
-fact, the [last Xorg release][] (21.1.0, October 2021) is [rumored to
-be the last][] ("just like the previous release...", that
-said). Indeed, it seems even core Xorg people have moved on to
-developing Wayland, or at least Xwayland, which was spun off it its
-own source tree.
+fact, the [last major Xorg release][] (21.1, October 2021) is [rumored
+to be the last][] ("just like the previous release...", that said,
+minor releases are still coming out, e.g. [21.1.4][]). Indeed, it
+seems even core Xorg people have moved on to developing Wayland, or at
+least Xwayland, which was spun off it its own source tree.
 
 X, or at least Xorg, in in maintenance mode and has been for
 years. Granted, the [X Window System][] is getting close to forty
@@ -113,11 +113,12 @@ Wayland fixed all of this.
 
 [artemis]: https://artemis.sh/2022/09/18/wayland-from-an-x-apologist.html
 [this blurb on LWN]: https://lwn.net/Articles/908561/
-[last Xorg release]: https://lists.x.org/archives/xorg/2021-October/060799.html
+[last major Xorg release]: https://lists.x.org/archives/xorg/2021-October/060799.html
 [rumored to be the last]: https://who-t.blogspot.com/2021/09/an-xorg-release-without-xwayland.html
 [X Window System]: https://en.wikipedia.org/wiki/X_Window_System
 [first]: https://en.wikipedia.org/wiki/Xerox_Alto
 [graphical interface]: https://en.wikipedia.org/wiki/Macintosh_128
+[21.1.4]: https://lists.x.org/archives/xorg-announce/2022-July/003193.html
 
 # Wayland equivalents
 

another stab against swap
diff --git a/software/zfs.md b/software/zfs.md
index 62973dd3..f78feebf 100644
--- a/software/zfs.md
+++ b/software/zfs.md
@@ -15,7 +15,8 @@
 
 Swap on ZFS volumes (AKA "swap on ZVOL") can trigger lockups and that
 issue is [still not fixed upstream][]. [Ubuntu recommends using a
-separate partition for swap instead][].
+separate partition for swap instead][]. [cks would rather have no swap
+that swap on ZFS][] and compares it to NFS...
 
 [[hardware/curie]] was setup without a swap partition (or, at least,
 hoping to use a ZFS dataset as a swap backend) but this has proven to
@@ -25,6 +26,7 @@ problems with ZFS encryption as well.
 
 [still not fixed upstream]: https://github.com/openzfs/zfs/issues/7734
 [Ubuntu recommends using a separate partition for swap instead]: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1847628
+[cks would rather have no swap that swap on ZFS]: https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSForSwapMyViews
 
 ### Native encryption
 

fix path to pipewire config, previous config hosed my audio
... and even broke firefox, which would totally hang while joining a
jitsi page.
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index cd63c425..c01a7fd6 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -1186,7 +1186,7 @@ Then, as a regular user:
 An optional (but key, IMHO) configuration you should also make is to
 "switch on connect", which will make your Bluetooth or USB headset
 automatically be the default route for audio, when connected. In
-`~/.config/pipewire/pipewire.conf`:
+`~/.config/pipewire/pipewire-pulse.conf.d/autoconnect.conf`:
 
     context.exec = [
         { path = "pactl"        args = "load-module module-always-sink" }
@@ -1195,7 +1195,11 @@ automatically be the default route for audio, when connected. In
     ]
 
 See the excellent — as usual — [Arch wiki page about Pipewire][] for
-that trick and more information about Pipewire.
+that trick and more information about Pipewire. Note that you must
+*not* put the file in `~/.config/pipewire/pipewire.conf` (or
+`pipewire-pulse.conf`, maybe) directly, as that will break your
+setup. If you want to add to that file, first copy the template from
+`/usr/share/pipewire/pipewire-pulse.conf` first.
 
 So far I'm happy with Pipewire in bookworm, but I've heard mixed
 reports from it. I have high hopes it will become the standard media

also needing wdisplays now
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index e9685f0c..cd63c425 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -24,8 +24,9 @@ happened, and what's left to do.
 TL;DR: Wayland is [mostly ready][arewewaylandyet.com]. Main blockers you might find are
 that you need to do manual configurations, [DisplayLink][] (multiple
 monitors on a single cable) doesn't work in Sway, HDR and color
-management are still in development. I installed the following
-packages:
+management are still in development.
+
+I had to install the following packages:
 
     apt install \
         brightnessctl \
@@ -37,6 +38,7 @@ packages:
         sway \
         swayidle \
         swaylock \
+        wdisplays \
         wev \
         wireplumber \
         wlr-randr \

chromium/signal fixed
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 963a8d64..e9685f0c 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -299,17 +299,24 @@ To start chrome with the Wayland backend, you need to use:
 
     chromium  -enable-features=UseOzonePlatform -ozone-platform=wayland
 
-Unfortunately, Chromium doesn't work as well as one would expect under
-Wayland. In Sway, it shows a huge gray border around the browser (!!).
+If it shows an ugly gray border, check the `Use system title bar and
+borders` setting.
 
-It *can* however, do *some* screensharing. Sharing a window and a tab
-seems to work, but sharing a full screen doesn't: it's all
-black. Definitely not ready for prime time. And since Firefox can do
-the right thing (mostly) under Wayland, I will not need to fight with
-Chromium to work under Wayland.
+It can do *some* screensharing. Sharing a window and a tab seems to
+work, but sharing a full screen doesn't: it's all black. Maybe not
+ready for prime time. 
+
+And since Firefox can do what I need under Wayland now, I will not
+need to fight with Chromium to work under Wayland:
 
     apt purge chromium
 
+Note that a similar fix was necessary for Signal Desktop, see [this
+commit](https://gitlab.com/anarcat/puppet/-/commit/c13b9c399882fd76817e408baf8312be3f94dce7). Basically you need to figure out a way to pass those same
+flags to signal:
+
+    --enable-features=WaylandWindowDecorations --ozone-platform-hint=auto
+
 ## Email: notmuch
 
 See Emacs, below.

fix date syntax error
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 34f3ff2b..963a8d64 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -1,5 +1,5 @@
 [[!meta title="Wayland: i3 to Sway migration"]]
-[[!meta date="202-11-16T17:04:10-0500"]]
+[[!meta date="2022-11-16T17:04:10-0500"]]
 
 I started migrating my graphical workstations to Wayland, specifically
 migrating from i3 to Sway. This is mostly to address serious graphics

punt article date so it's at the top of the blog roll
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 72fc343a..34f3ff2b 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -1,4 +1,5 @@
 [[!meta title="Wayland: i3 to Sway migration"]]
+[[!meta date="202-11-16T17:04:10-0500"]]
 
 I started migrating my graphical workstations to Wayland, specifically
 migrating from i3 to Sway. This is mostly to address serious graphics

publish wayland hacking as a blog post
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 5ee15309..72fc343a 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -1305,6 +1305,6 @@ screen right now, or always". Applications themselves *might* have
 these kind of dialogs enabled, but it's mostly absent, and that is
 worrisome.
 
-TODO: tags, publish as a blog?
-
 [Wikipedia describes the security properties of Wayland]: https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Comparison_with_other_window_systems
+
+[[!tag unix wayland blog desktop firefox emacs debian debian-planet]]

more test results
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index c5c19d07..5ee15309 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -333,7 +333,14 @@ So we'll probably need to wait for Emacs 29 to have native Wayland
 support in Emacs, which, in turn, is unlikely to arrive in time for
 the [Debian bookworm freeze][]. There are, however, [unofficial
 builds][] for both Emacs 28 and 29 provided by [spwhitton][] which
-may provide native Wayland support.
+may provide native Wayland support. 
+
+I tested the snapshot packages and they do not quite work well
+enough. First off, they completely take over the builtin Emacs — they
+hijack the `$PATH` in `/etc`! — and certain things are simply not
+working in my setup. For example, this hook never gets ran on startup:
+
+    (add-hook 'after-init-hook 'server-start t) 
 
 Still, like many X11 applications, Emacs mostly works fine under
 Xwayland. The clipboard works as expected, for example.
@@ -341,7 +348,8 @@ Xwayland. The clipboard works as expected, for example.
 Scaling is a bit of an issue: fonts look fuzzy.
 
 I have heard anecdotal evidence of hard lockups with Emacs running
-under Xwayland as well, but haven't experienced any problem so far.
+under Xwayland as well, but haven't experienced any problem so far. I
+did experience a Wayland crash with the snapshot version however.
 
 TODO: look again at Wayland in Emacs 29.
 
@@ -390,12 +398,19 @@ associated with the [[sway-session.target]].
 
 ## Display manager: lightdm → gdm3
 
-Switched because lightdm failed to start sway. TODO: try lightdm
-again, see also those alternatives:
+Switched because lightdm failed to start sway:
+
+    nov 16 16:41:43 angela sway[843121]: 00:00:00.002 [ERROR] [wlr] [libseat] [common/terminal.c:162] Could not open target tty: Permission denied
+
+Possible alternatives:
 
- * [lightdm elephant greeter][]
- * [greetd][] and [QtGreet][]
- * [sddm][]: KDE's default
+ * [lightdm elephant greeter][] (I tried [[!debpkg slick-greeter]] and
+   [[!debpkg ukui-greeter]], neither could start the Sway session)
+ * [greetd][] and [QtGreet][] (former in Debian, not latter, which
+   means we're stuck with the weird [agreety](https://manpages.debian.org/agreety) which doesn't work at
+   all)
+ * [sddm][]: KDE's default, in Debian, probably heavier or as heavy as
+   gdm3
 
 [lightdm elephant greeter]: https://github.com/max-moser/lightdm-elephant-greeter
 [greetd]: https://sr.ht/~kennylevinsen/greetd/

cleanup the autorandr section and headings
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index a690eecc..c5c19d07 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -872,6 +872,7 @@ case, they should be listed here:
 
 | X11          | Wayland               | In Debian |
 |--------------|-----------------------|-----------|
+| `arandr`     | [wdisplays][]         | yes       |
 | `autorandr`  | [kanshi][]            | yes       |
 | `xdotool`    | [wtype][]             | yes       |
 | `xev`        | [wev][]               | yes       |
@@ -891,25 +892,21 @@ See also:
  * <https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway>
  * <https://github.com/swaywm/sway/wiki/i3-Migration-Guide>
 
-TODO: `autorandr` conversion... [kanshi][]? see [this service
-file][]. wallutils can also do this, apparently.
-
 [this service file]: https://github.com/xdbob/sway-services/blob/master/systemd/kanshi.service
 
-### arandr → wdisplays
-
-arandr is not directly part of X, but there's also no cleary
-established equivalent... [arewewaylandyet.com][] refers to a few:
+Note that arandr and autorandr are not directly part of
+X. [arewewaylandyet.com][] refers to a few alternatives. We suggest
+[wdisplays][] and [kanshi][] above (see also [this service
+file][]) but [wallutils][] can also do the autorandr stuff, apparently,
+and [nwg-displays][] can do the arandr part. Neither are packaged in
+Debian yet.
 
-| Project          | In Debian |
-|------------------|-----------|
-| [wdisplays][]    | yes       |
-| [nwg-displays][] | no        |
-
-I have tried [wdisplays][] and it Just Works, and well. The UI even
+So I have tried [wdisplays][] and it Just Works, and well. The UI even
 looks better and more usable than arandr, so another clean win from
 Wayland here.
 
+TODO: test [kanshi][] as a autorandr replacement
+
 [wdisplays]: https://github.com/artizirk/wdisplays
 [nwg-displays]: https://github.com/nwg-piotr/nwg-displays
 

fix all links
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 582e1d61..a690eecc 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -21,7 +21,7 @@ The rest of this page documents why I made the switch, how it
 happened, and what's left to do.
 
 TL;DR: Wayland is [mostly ready][arewewaylandyet.com]. Main blockers you might find are
-that you need to do manual configurations, [DisplayLink](https://en.wikipedia.org/wiki/DisplayLink) (multiple
+that you need to do manual configurations, [DisplayLink][] (multiple
 monitors on a single cable) doesn't work in Sway, HDR and color
 management are still in development. I installed the following
 packages:
@@ -47,13 +47,15 @@ not a fan.
 
 [[!toc levels=5]]
 
+[DisplayLink]: https://en.wikipedia.org/wiki/DisplayLink
+
 # Why switch?
 
 I originally held back from migrating to Wayland: it seemed like a
 complicated endeavor hardly worth the cost. It also didn't seem
 actually ready.
 
-But after reading [this blurb on LWN](https://lwn.net/Articles/908561/), I decided to at least
+But after reading [this blurb on LWN][], I decided to at least
 document the situation here. The actual quote that convinced me it
 might be worth it was:
 
@@ -67,17 +69,17 @@ worth a read as well][artemis].
 The point here is not to bash one side or the other, or even do a
 thorough comparison. I start with the premise that Xorg is likely
 going away in the future and that I will need to adapt some day. In
-fact, the [last Xorg release](https://lists.x.org/archives/xorg/2021-October/060799.html) (21.1.0, October 2021) is [rumored to
-be the last](https://who-t.blogspot.com/2021/09/an-xorg-release-without-xwayland.html) ("just like the previous release...", that
+fact, the [last Xorg release][] (21.1.0, October 2021) is [rumored to
+be the last][] ("just like the previous release...", that
 said). Indeed, it seems even core Xorg people have moved on to
 developing Wayland, or at least Xwayland, which was spun off it its
 own source tree.
 
 X, or at least Xorg, in in maintenance mode and has been for
-years. Granted, the [X Window System](https://en.wikipedia.org/wiki/X_Window_System) is getting close to forty
+years. Granted, the [X Window System][] is getting close to forty
 years old at this point: it got us amazingly far for something that
-was designed around the time the [first](https://en.wikipedia.org/wiki/Xerox_Alto) [graphical
-interface](https://en.wikipedia.org/wiki/Macintosh_128). Since Mac and (especially?) Windows released theirs,
+was designed around the time the [first][] [graphical
+interface][]. Since Mac and (especially?) Windows released theirs,
 they have rebuilt their graphical backends numerous times, but UNIX
 derivatives have stuck on Xorg this entire time, which is a testament
 to the design and reliability of X. (Or our incapacity at developing
@@ -107,6 +109,12 @@ all. Video playback in a window was laggy, sluggish, and out of sync.
 Wayland fixed all of this.
 
 [artemis]: https://artemis.sh/2022/09/18/wayland-from-an-x-apologist.html
+[this blurb on LWN]: https://lwn.net/Articles/908561/
+[last Xorg release]: https://lists.x.org/archives/xorg/2021-October/060799.html
+[rumored to be the last]: https://who-t.blogspot.com/2021/09/an-xorg-release-without-xwayland.html
+[X Window System]: https://en.wikipedia.org/wiki/X_Window_System
+[first]: https://en.wikipedia.org/wiki/Xerox_Alto
+[graphical interface]: https://en.wikipedia.org/wiki/Macintosh_128
 
 # Wayland equivalents
 
@@ -122,7 +130,7 @@ possibly moving old configs to a [[software/desktop/xorg]] archive.
 
 ## Window manager: i3 → sway
 
-This seems like kind of a no-brainer. [Sway](http://swaywm.org/) is around, it's
+This seems like kind of a no-brainer. [Sway][] is around, it's
 feature-complete, and it's in Debian.
 
 I'm a bit worried about the "Drew DeVault community", to be
@@ -132,12 +140,12 @@ like containers and systemd that make it hard to do my work while
 interacting with that community.
 
 I'm also concern about the lack of unit tests and user manual for
-Sway. The [i3 window manager](https://i3wm.org/) has been designed by a fellow
+Sway. The [i3 window manager][] has been designed by a fellow
 (ex-)Debian developer I have a lot of respect for ([Michael
-Stapelberg](https://michael.stapelberg.ch/)), partly because of i3 itself, but also working with
-him on [other projects](https://manpages.debian.org). Beyond the characters, i3 has a [user
-guide](https://i3wm.org/docs/userguide.html), a [code of conduct](https://i3wm.org/conduct.html), and [lots more
-documentation](https://i3wm.org/docs/). It has a [test suite](https://github.com/i3/i3/tree/next/testcases).
+Stapelberg][]), partly because of i3 itself, but also working with
+him on [other projects][]. Beyond the characters, i3 has a [user
+guide][], a [code of conduct][], and [lots more
+documentation][]. It has a [test suite][].
 
 Sway has... manual pages, with the homepage just telling users to use
 `man -k sway` to find what they need. I don't think we need that kind
@@ -159,27 +167,42 @@ actually a lot) were *all* **Wayland-specific** changes, not
 
 See a copy of my full [[sway/config|config]] for details.
 
+[Sway]: http://swaywm.org/
+[i3 window manager]: https://i3wm.org/
+[Michael Stapelberg]: https://michael.stapelberg.ch/
+[other projects]: https://manpages.debian.org
+[user guide]: https://i3wm.org/docs/userguide.html
+[code of conduct]: https://i3wm.org/conduct.html
+[lots more documentation]: https://i3wm.org/docs/
+[test suite]: https://github.com/i3/i3/tree/next/testcases
+
 ## Status bar: py3status
 
 I have invested quite a bit of effort in setting up my status bar with
-[py3status](https://py3status.readthedocs.io/). It supports Sway directly, and did not actually
+[py3status][]. It supports Sway directly, and did not actually
 require any change when migrating to Wayland. Awesome.
 
+[py3status]: https://py3status.readthedocs.io/
+
 ## Web browser: Firefox
 
 Firefox has had support for Wayland for a while now, with the team
-[enabling it by default in nightlies around January 2022](https://www.phoronix.com/news/Firefox-Nightly-Wayland-Rolling). It's
+[enabling it by default in nightlies around January 2022][]. It's
 actually not easy to figure out the state of the port, the [meta bug
-report](https://bugzilla.mozilla.org/show_bug.cgi?id=635134) is still open and it's *huge*: it currently (Sept 2022)
+report][] is still open and it's *huge*: it currently (Sept 2022)
 depends on 76 open bugs, it was opened *twelve* (2010) years ago, and
 it's still getting daily updates (mostly linking to other tickets).
 
-[Firefox 106](https://www.mozilla.org/en-US/firefox/106.0/releasenotes/) presumably shipped with "Better screen sharing for
+[Firefox 106][] presumably shipped with "Better screen sharing for
 Windows and Linux Wayland users", but I couldn't quite figure out what
 those were.
 
 TL;DR: `echo MOZ_ENABLE_WAYLAND=1 >> ~/.config/environment.d/firefox.conf && apt install xdg-desktop-portal-wlr`
 
+[enabling it by default in nightlies around January 2022]: https://www.phoronix.com/news/Firefox-Nightly-Wayland-Rolling
+[meta bug report]: https://bugzilla.mozilla.org/show_bug.cgi?id=635134
+[Firefox 106]: https://www.mozilla.org/en-US/firefox/106.0/releasenotes/
+
 ### How to enable it
 
 Firefox depends on this silly variable to start correctly under
@@ -198,7 +221,7 @@ environment startup script:
 At least that's the theory. In practice, Sway doesn't actually run any
 startup shell script, so that can't possibly work. Furthermore,
 `XDG_SESSION_TYPE` is not actually set when starting Sway from `gdm3`
-which I find really confusing, and I'm not the [only](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021545) [one](https://github.com/swaywm/sway/pull/4876). So
+which I find really confusing, and I'm not the [only][] [one][]. So
 the above trick doesn't actually work, even if the environment
 (`XDG_SESSION_TYPE`) *is* set correctly, because we don't have
 conditionals in [environment.d(5)][].
@@ -210,7 +233,7 @@ solution to have a conditional `MOZ_ENABLE_WAYLAND` environment, but
 I'm not sure it would work because ordering between those two isn't
 clear: maybe the `XDG_SESSION_TYPE` wouldn't be set just yet...)
 
-At first, I made [this ridiculous script](https://gitlab.com/anarcat/scripts/-/blob/3184996fa3e8050aed07451c16b72d69bcb2cd1b/firefox) to workaround those
+At first, I made [this ridiculous script][] to workaround those
 issues. Really, it seems to me Firefox should just parse the
 `XDG_SESSION_TYPE` variable here... but then I realized that Firefox
 works fine in Xorg when the `MOZ_ENABLE_WAYLAND` is set.
@@ -219,11 +242,15 @@ So now I just set that variable in `environment.d` and It Just Works™:
 
     MOZ_ENABLE_WAYLAND=1
 
+[only]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021545
+[one]: https://github.com/swaywm/sway/pull/4876
+[this ridiculous script]: https://gitlab.com/anarcat/scripts/-/blob/3184996fa3e8050aed07451c16b72d69bcb2cd1b/firefox
+
 ### Screen sharing
 
 Out of the box, screen sharing doesn't work until you install
-[xdg-desktop-portal-wlr](https://github.com/emersion/xdg-desktop-portal-wlr/) or similar
-(e.g. [xdg-desktop-portal-gnome](https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome) on GNOME). I had to reboot for the
+[xdg-desktop-portal-wlr][] or similar
+(e.g. [xdg-desktop-portal-gnome][] on GNOME). I had to reboot for the
 change to take effect.
 
 Without those tools, it shows the usual permission prompt with "Use
@@ -235,23 +262,30 @@ This was tested in Debian bookworm/testing with Firefox ESR 102 and
 Firefox 106.
 
 Major caveat: we can only share a full screen, we [can't currently
-share just a window](https://github.com/emersion/xdg-desktop-portal-wlr/wiki/FAQ#will-this-let-me-share-individual-windows). The major upside to that is that, by default,
-it streams *only* [one output](https://github.com/emersion/xdg-desktop-portal-wlr/wiki/FAQ#will-this-let-me-share-all-of-my-outputsdisplays-at-once) which is actually what I want most
-of the time! See the [screencast compatibility](https://github.com/emersion/xdg-desktop-portal-wlr/wiki/Screencast-Compatibility) for more
+share just a window][]. The major upside to that is that, by default,
+it streams *only* [one output][] which is actually what I want most
+of the time! See the [screencast compatibility][] for more
 information on what is supposed to work.
 
 This is actually a *huge* improvement over the situation in Xorg,
-where Firefox [can only share a window or all monitors](https://bugzilla.mozilla.org/show_bug.cgi?id=1412333), which led
+where Firefox [can only share a window or all monitors][], which led
 me to use Chromium a lot for video-conferencing. With this change, in
 other words, I will not need Chromium for anything anymore, whoohoo!
 
 If [[!debpkg slurp]], [[!debpkg wofi]], or [[!debpkg bemenu]] are
 installed, one of them will be used to pick the monitor to share,
 which effectively acts as some minimal security measure. See
-[xdg-desktop-portal-wlr(1)](https://manpages.debian.org/xdg-desktop-portal-wlr) for how to configure that.
+[xdg-desktop-portal-wlr(1)][] for how to configure that.
 

(Diff truncated)
creating tag page tag/zfs
diff --git a/tag/zfs.mdwn b/tag/zfs.mdwn
new file mode 100644
index 00000000..d463f88d
--- /dev/null
+++ b/tag/zfs.mdwn
@@ -0,0 +1,4 @@
+[[!meta title="pages tagged zfs"]]
+
+[[!inline pages="tagged(zfs)" actions="no" archive="yes"
+feedshow=10]]

publish zfs migration blog post
diff --git a/blog/2016-01-31-free-software-activities-january-2016.mdwn b/blog/2016-01-31-free-software-activities-january-2016.mdwn
index b87f9e1b..6cdaca0a 100644
--- a/blog/2016-01-31-free-software-activities-january-2016.mdwn
+++ b/blog/2016-01-31-free-software-activities-january-2016.mdwn
@@ -427,4 +427,4 @@ personally.
  [i18n]: https://github.com/borgbackup/borg/pull/305
  [support timeframe and compatibility policy]: https://github.com/borgbackup/borg/issues/26
 
-[[!tag monthly-report debian-planet debian python-planet software geek free debian-lts borg backups systemd ledger timetracker kodi git]]
+[[!tag monthly-report debian-planet debian python-planet software geek free debian-lts borg backup systemd ledger timetracker kodi git]]
diff --git a/blog/2022-11-17-zfs-migration.md b/blog/2022-11-17-zfs-migration.md
index 12765116..06d3e8de 100644
--- a/blog/2022-11-17-zfs-migration.md
+++ b/blog/2022-11-17-zfs-migration.md
@@ -1424,4 +1424,4 @@ this.
 See the [[software/zfs]] documentation for more information about ZFS,
 and [[hardware/tubman]] for another installation and migration procedure.
 
-[[!tag draft]]
+[[!tag zfs debian-planet sysadmin debian backup]]
diff --git a/tag/backups.mdwn b/tag/backups.mdwn
deleted file mode 100644
index 5f92a4c8..00000000
--- a/tag/backups.mdwn
+++ /dev/null
@@ -1,4 +0,0 @@
-[[!meta title="pages tagged backups"]]
-
-[[!inline pages="tagged(backups)" actions="no" archive="yes"
-feedshow=10]]

move more TODOs into common page
diff --git a/blog/2022-11-17-zfs-migration.md b/blog/2022-11-17-zfs-migration.md
index db721944..12765116 100644
--- a/blog/2022-11-17-zfs-migration.md
+++ b/blog/2022-11-17-zfs-migration.md
@@ -1160,11 +1160,8 @@ SMART self-test succeeded.
 - TODO: move send/receive backups to offsite host, see also
   [[software/zfs]] for alternatives to syncoid/sanoid there
 - TODO: setup backup cron job (or timer?)
-- TODO: swap. how do we do it? see also tubman
+- TODO: swap still not setup on curie, see [[software/zfs#swap]]
 - TODO: [TRIM][] on curie
-- TODO: ship my on .debs? `dkms mkbmdeb zfs/2.0.3` is the magic
-  command here. see also [this idea in grml](https://github.com/grml/grml-live/issues/78) and [this packaging
-  attempt](https://github.com/ChibaPet/bliss-zfs)
 - TODO: document this somewhere: bpool and rpool are both pools and
   datasets. that's pretty confusing, but also very useful because it
   allows for pool-wide recursive snapshots, which are used for the
diff --git a/software/zfs.md b/software/zfs.md
index 63bd3769..62973dd3 100644
--- a/software/zfs.md
+++ b/software/zfs.md
@@ -2,6 +2,107 @@
 
 [[!toc levels=5]]
 
+# Installation
+
+## Example installations
+
+ * [[Migration of a workstation to ZFS|blog/2022-11-17-zfs-migration]]
+ * [[New server installation|hardware/tubman]]
+
+## Issues
+
+### Swap
+
+Swap on ZFS volumes (AKA "swap on ZVOL") can trigger lockups and that
+issue is [still not fixed upstream][]. [Ubuntu recommends using a
+separate partition for swap instead][].
+
+[[hardware/curie]] was setup without a swap partition (or, at least,
+hoping to use a ZFS dataset as a swap backend) but this has proven to
+be generally a bad idea. Were we to setup a new ZFS system, we'd use
+LUKS encryption and setup a dedicated swap partition, as we had
+problems with ZFS encryption as well.
+
+[still not fixed upstream]: https://github.com/openzfs/zfs/issues/7734
+[Ubuntu recommends using a separate partition for swap instead]: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1847628
+
+### Native encryption
+
+ZFS supports native encryption, but there are serious caveats with
+it.
+
+I've had trouble moving encrypted datasets between pools when trying
+to move the [[hardware/tubman]] `rpool` from HDDs to SSDs. This is a
+problem many people are facing, without good solutions, see also [this
+truenas discussion](https://www.truenas.com/community/threads/cant-zfs-send-between-encrypted-pools.90532/), [this reddit thread](https://www.reddit.com/r/zfs/comments/dkldqr/having_trouble_using_sendreceive_on_encrypted/), [this openzfs docs
+thread](https://github.com/openzfs/openzfs-docs/issues/354), and [this other one](https://github.com/openzfs/openzfs-docs/pull/127#issuecomment-785491091).
+
+Also, native encryption "will not encrypt metadata related to the pool
+structure, including dataset and snapshot names, dataset hierarchy,
+properties, file size, file holes, and deduplication tables (though
+the deduplicated data itself is encrypted)." So it will leak
+some metadata about the filesystem. Deduplication is limited to the
+dataset level.
+
+Therefore, it might be better to use LUKS encryption underneath ZFS to
+configure fully encrypted systems, although I haven't tested this directly.
+
+## TRIM
+
+I enabled (a little late) TRIM on the SSD pools:
+
+    zfs set org.debian:periodic-trim=enable bpoolssd
+    zfs set org.debian:periodic-trim=enable rpoolssd
+
+That will setup periodic TRIMs, but it's also possible to set the
+equivalent of "discard" that "looks for space which has been recently
+freed, and is no longer allocated by the pool, to be periodically
+trimmed, however it does not immediately reclaim blocks after a free,
+which makes it very effective at a cost of more likely of encountering
+tiny ranges."
+
+    zpool set autotrim=on bpoolssd
+    zpool set autotrim=on rpoolssd
+
+You can do a manual trim with:
+
+    zpool trim bpoolssd
+    zpool trim rpoolssd
+
+Here's an example run:
+
+    root@tubman:/etc# zpool status -t rpoolssd
+      pool: rpoolssd
+     state: ONLINE
+      scan: scrub repaired 0B in 00:00:37 with 0 errors on Sun Nov 13 00:24:38 2022
+    config:
+
+    	NAME        STATE     READ WRITE CKSUM
+    	rpoolssd    ONLINE       0     0     0
+    	 mirror-0  ONLINE       0     0     0
+    	   sdb4    ONLINE       0     0     0  (untrimmed)
+    	   sdd4    ONLINE       0     0     0  (untrimmed)
+
+    errors: No known data errors
+    root@tubman:/etc# zpool trim rpoolssd
+    root@tubman:/etc# zpool status -t rpoolssd
+      pool: rpoolssd
+     state: ONLINE
+      scan: scrub repaired 0B in 00:00:37 with 0 errors on Sun Nov 13 00:24:38 2022
+    config:
+
+    	NAME        STATE     READ WRITE CKSUM
+    	rpoolssd    ONLINE       0     0     0
+    	 mirror-0  ONLINE       0     0     0
+    	   sdb4    ONLINE       0     0     0  (3% trimmed, started at Wed 16 Nov 2022 12:19:04 PM EST)
+    	   sdd4    ONLINE       0     0     0  (3% trimmed, started at Wed 16 Nov 2022 12:19:04 PM EST)
+
+    errors: No known data errors
+
+See also the [TRIM documentation in the Debian wiki][TRIM].
+
+[TRIM]: https://wiki.debian.org/ZFS#TRIM_support
+
 # Information
 
 Listing partitions and snapshots:
@@ -146,63 +247,6 @@ tools, fairly minimalist.
 
 Packaged in Debian.
 
-# Other settings
-## TRIM
-
-I enabled (a little late) TRIM on the SSD pools:
-
-    zfs set org.debian:periodic-trim=enable bpoolssd
-    zfs set org.debian:periodic-trim=enable rpoolssd
-
-That will setup periodic TRIMs, but it's also possible to set the
-equivalent of "discard" that "looks for space which has been recently
-freed, and is no longer allocated by the pool, to be periodically
-trimmed, however it does not immediately reclaim blocks after a free,
-which makes it very effective at a cost of more likely of encountering
-tiny ranges."
-
-    zpool set autotrim=on bpoolssd
-    zpool set autotrim=on rpoolssd
-
-You can do a manual trim with:
-
-    zpool trim bpoolssd
-    zpool trim rpoolssd
-
-Here's an example run:
-
-    root@tubman:/etc# zpool status -t rpoolssd
-      pool: rpoolssd
-     state: ONLINE
-      scan: scrub repaired 0B in 00:00:37 with 0 errors on Sun Nov 13 00:24:38 2022
-    config:
-
-    	NAME        STATE     READ WRITE CKSUM
-    	rpoolssd    ONLINE       0     0     0
-    	 mirror-0  ONLINE       0     0     0
-    	   sdb4    ONLINE       0     0     0  (untrimmed)
-    	   sdd4    ONLINE       0     0     0  (untrimmed)
-
-    errors: No known data errors
-    root@tubman:/etc# zpool trim rpoolssd
-    root@tubman:/etc# zpool status -t rpoolssd
-      pool: rpoolssd
-     state: ONLINE
-      scan: scrub repaired 0B in 00:00:37 with 0 errors on Sun Nov 13 00:24:38 2022
-    config:
-
-    	NAME        STATE     READ WRITE CKSUM
-    	rpoolssd    ONLINE       0     0     0
-    	 mirror-0  ONLINE       0     0     0
-    	   sdb4    ONLINE       0     0     0  (3% trimmed, started at Wed 16 Nov 2022 12:19:04 PM EST)
-    	   sdd4    ONLINE       0     0     0  (3% trimmed, started at Wed 16 Nov 2022 12:19:04 PM EST)
-
-    errors: No known data errors
-
-See also the [TRIM documentation in the Debian wiki][TRIM].
-
-[TRIM]: https://wiki.debian.org/ZFS#TRIM_support
-
 # Caveats
 
 ## Empty datasets
@@ -238,21 +282,20 @@ rename, if not empty) the directory, and remount the dataset:
     rmdir /mnt/foo || mv /mnt/foo /mnt/foo.bak
     zfs mount pool/foo
 
-## Native encryption
+## Not mainline
 

(Diff truncated)
cosmetic
diff --git a/blog/2022-11-17-zfs-migration.md b/blog/2022-11-17-zfs-migration.md
index ffa5473e..db721944 100644
--- a/blog/2022-11-17-zfs-migration.md
+++ b/blog/2022-11-17-zfs-migration.md
@@ -1031,7 +1031,7 @@ TODO: this should be in Puppet
 So what happens when problems are found? Here's an example of how I
 dealt with an error I received.
 
-After setting up another server [[hardware/tubman]] with ZFS, I
+After setting up another server ([[hardware/tubman]]) with ZFS, I
 eventually ended up getting a warning from the ZFS toolchain.
 
     Date: Sun, 09 Oct 2022 00:58:08 -0400

setup trim on tubman
diff --git a/blog/2022-11-17-zfs-migration.md b/blog/2022-11-17-zfs-migration.md
index aa01de7b..ffa5473e 100644
--- a/blog/2022-11-17-zfs-migration.md
+++ b/blog/2022-11-17-zfs-migration.md
@@ -1161,7 +1161,7 @@ SMART self-test succeeded.
   [[software/zfs]] for alternatives to syncoid/sanoid there
 - TODO: setup backup cron job (or timer?)
 - TODO: swap. how do we do it? see also tubman
-- TODO: [TRIM][], also on tubman!
+- TODO: [TRIM][] on curie
 - TODO: ship my on .debs? `dkms mkbmdeb zfs/2.0.3` is the magic
   command here. see also [this idea in grml](https://github.com/grml/grml-live/issues/78) and [this packaging
   attempt](https://github.com/ChibaPet/bliss-zfs)
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 40232f51..1a71dd9d 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -1206,6 +1206,10 @@ install guides, which put most datasets directly on the root dataset
 adding that layer of indirection could help with such situations, but
 the jury is actually still out on that, see [this discussion](https://github.com/openzfs/openzfs-docs/issues/354).
 
+## SSD TRIM
+
+See [[software/zfs#trim]].
+
 ## extending the main tank
 
 Once we are confident we can boot without the old HDD pool, we can
diff --git a/software/zfs.md b/software/zfs.md
index 12ae1076..63bd3769 100644
--- a/software/zfs.md
+++ b/software/zfs.md
@@ -146,6 +146,63 @@ tools, fairly minimalist.
 
 Packaged in Debian.
 
+# Other settings
+## TRIM
+
+I enabled (a little late) TRIM on the SSD pools:
+
+    zfs set org.debian:periodic-trim=enable bpoolssd
+    zfs set org.debian:periodic-trim=enable rpoolssd
+
+That will setup periodic TRIMs, but it's also possible to set the
+equivalent of "discard" that "looks for space which has been recently
+freed, and is no longer allocated by the pool, to be periodically
+trimmed, however it does not immediately reclaim blocks after a free,
+which makes it very effective at a cost of more likely of encountering
+tiny ranges."
+
+    zpool set autotrim=on bpoolssd
+    zpool set autotrim=on rpoolssd
+
+You can do a manual trim with:
+
+    zpool trim bpoolssd
+    zpool trim rpoolssd
+
+Here's an example run:
+
+    root@tubman:/etc# zpool status -t rpoolssd
+      pool: rpoolssd
+     state: ONLINE
+      scan: scrub repaired 0B in 00:00:37 with 0 errors on Sun Nov 13 00:24:38 2022
+    config:
+
+    	NAME        STATE     READ WRITE CKSUM
+    	rpoolssd    ONLINE       0     0     0
+    	 mirror-0  ONLINE       0     0     0
+    	   sdb4    ONLINE       0     0     0  (untrimmed)
+    	   sdd4    ONLINE       0     0     0  (untrimmed)
+
+    errors: No known data errors
+    root@tubman:/etc# zpool trim rpoolssd
+    root@tubman:/etc# zpool status -t rpoolssd
+      pool: rpoolssd
+     state: ONLINE
+      scan: scrub repaired 0B in 00:00:37 with 0 errors on Sun Nov 13 00:24:38 2022
+    config:
+
+    	NAME        STATE     READ WRITE CKSUM
+    	rpoolssd    ONLINE       0     0     0
+    	 mirror-0  ONLINE       0     0     0
+    	   sdb4    ONLINE       0     0     0  (3% trimmed, started at Wed 16 Nov 2022 12:19:04 PM EST)
+    	   sdd4    ONLINE       0     0     0  (3% trimmed, started at Wed 16 Nov 2022 12:19:04 PM EST)
+
+    errors: No known data errors
+
+See also the [TRIM documentation in the Debian wiki][TRIM].
+
+[TRIM]: https://wiki.debian.org/ZFS#TRIM_support
+
 # Caveats
 
 ## Empty datasets

scrub setup in tubman
diff --git a/blog/2022-11-17-zfs-migration.md b/blog/2022-11-17-zfs-migration.md
index 10943684..aa01de7b 100644
--- a/blog/2022-11-17-zfs-migration.md
+++ b/blog/2022-11-17-zfs-migration.md
@@ -1009,8 +1009,9 @@ zed]] daemon monitors all ZFS events. It is the thing that will report
 when a scrub failed, for example. See [this configuration guide][].
 
 Scrubs should be regularly scheduled to ensure consistency of the
-pool. This can be done in newer zfsutils-linux versions with one of
-those, depending on the desired frequency:
+pool. This can be done in newer [[!debpkg zfsutils-linux]] versions
+(bullseye-backports or bookworm) with one of those, depending on the
+desired frequency:
 
     systemctl enable zfs-scrub-weekly@rpool.timer --now
 
@@ -1021,7 +1022,7 @@ will get picked up by the `zed` daemon which will then send a
 notification, see below for an example.
 
 TODO: deploy on curie, if possible (probably not because no RAID)
-TODO: check if it's setup on tubman properly.
+TODO: this should be in Puppet
 
 [this configuration guide]: https://pieterbakker.com/monitoring-zfs-with-zed/
 

rename zfs migration page
diff --git a/blog/zfs-migration.md b/blog/2022-11-17-zfs-migration.md
similarity index 98%
rename from blog/zfs-migration.md
rename to blog/2022-11-17-zfs-migration.md
index 4720494a..10943684 100644
--- a/blog/zfs-migration.md
+++ b/blog/2022-11-17-zfs-migration.md
@@ -1,3 +1,5 @@
+[[!meta title="A ZFS migration"]]
+
 In my [[hardware/tubman]] setup, I started using ZFS on an old server
 I had lying around. The machine is really old though (2011!) and it
 "feels" pretty slow. I want to see how much of that is ZFS and how
@@ -104,6 +106,11 @@ workstation, we're betting that we will not suffer from this problem,
 after hearing a report from another Debian developer running this
 setup on their workstation successfully.
 
+We do not recommend this setup though. In fact, if I were to redo this
+partition scheme, I would probably use LUKS encryption and setup a
+dedicated swap partition, as I had problems with ZFS encryption as
+well.
+
 [doesn't support SMART commands]: https://www.smartmontools.org/ticket/1054
 [still not fixed upstream]: https://github.com/openzfs/zfs/issues/7734
 [Ubuntu recommends using a separate partition for swap instead]: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1847628
@@ -233,7 +240,7 @@ which typically just blinks out of existence completely, and doesn't
 
 Also, the [FreeBSD handbook quick start][] doesn't have any warnings
 about their first example, which is with a single disk. So I am
-reassured at least. All
+reassured at least.
 
 [rumoured to be more dangerous]: https://www.truenas.com/community/threads/single-drive-zfs.35515/
 [FreeBSD handbook quick start]: https://docs.freebsd.org/en/books/handbook/zfs/#zfs-quickstart-single-disk-pool
@@ -252,15 +259,19 @@ the things that get mounted on mountpoint and hold the actual files.
    they seem common practice, also used in [this FreeBSD
    example][]. The [OpenZFS guide][] mentions the Solaris upgrades and
    Ubuntu's zsys that use that container for upgrades and rollbacks.
+   This [blog post][] seems to explain a bit the layout behind the
+   installer.
+
+[blog post]:  https://github.com/djacu/nixos-on-zfs/blob/main/blog/2022-03-24.md
 
- * this actually creates the boot and root filesystems:
+ * this creates the actual boot and root filesystems:
 
         zfs create -o canmount=noauto -o mountpoint=/ rpool/ROOT/debian &&
         zfs mount rpool/ROOT/debian &&
         zfs create -o mountpoint=/boot bpool/BOOT/debian
 
    I guess the `debian` name here is because we could technically have
-   multiple operating systems with the same underlying datasets?
+   multiple operating systems with the same underlying datasets.
 
  * then the main datasets:
 
@@ -285,7 +296,10 @@ the things that get mounted on mountpoint and hold the actual files.
    
         cannot create 'rpool/var/lib/docker': parent does not exist
 
-   ... and no, just creating `/mnt/var/lib` doesn't fix that problem.
+   ... and no, just creating `/mnt/var/lib` doesn't fix that
+   problem. In fact, it makes things even more confusing because an
+   existing directory *shadows* a mountpoint, which is the opposite of
+   how things normally work.
 
    Also note that you will *probably* need to change storage driver in
    Docker, see the [zfs-driver documentation][] for details but,
@@ -293,8 +307,7 @@ the things that get mounted on mountpoint and hold the actual files.
    
        echo '{ "storage-driver": "zfs" }' > /etc/docker/daemon.json
 
-   Note, as an aside, that podman has the same problem (and similar
-   solution):
+   Note that podman has the same problem (and similar solution):
    
        printf '[storage]\ndriver = "zfs"\n' > /etc/containers/storage.conf
 
@@ -416,13 +429,15 @@ seems to be at around 5Gbps:
             ID 0b05:1932 ASUSTek Computer, Inc.
 
 So it shouldn't cap at that speed. It's possible the USB adapter is
-failing to give me the full speed though.
+failing to give me the full speed though. It's not the M.2 SSD drive
+either, as that has a ~500MB/s bandwidth, acccording to its spec.
 
 At this point, we're about ready to do the final configuration. We
 drop to single user mode and do the rest of the procedure. That used
 to be `shutdown now`, but it seems like the systemd switch broke that,
 so now you can reboot into grub and pick the "recovery"
-option. Alternatively, you might try `systemctl rescue` (untested).
+option. Alternatively, you might try `systemctl rescue`, as [I found
+out](https://github.com/systemd/systemd/pull/24928).
 
 I also wanted to copy the drive over to another new NVMe drive, but
 that failed: it looks like the USB controller I have doesn't work with
@@ -488,7 +503,7 @@ example you might want to tag both drives in a RAID array:
 
     dpkg-reconfigure grub-pc
 
-Possibly install grub to EFI?
+Install grub to EFI while you're there:
 
     grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian --recheck --no-floppy
 
@@ -597,7 +612,7 @@ because we're not actually NVMe (this is an old workstation!) so the
 bottleneck isn't the disk itself. For our purposes, it might still
 give us useful results.
 
-### Rescue test, mdadm/luks/lvm/ext4
+### Rescue test, LUKS/LVM/ext4
 
 Those tests were performed with everything shutdown, after either
 entering the system in rescue mode, or by reaching that target with:
@@ -628,7 +643,9 @@ Peaks are at about 20k IOPS and ~1.3GiB/s read, 1GiB/s write in the
 Slowest is the random 4k block sync write at an abysmal 3MB/s and 700
 IOPS The 1MB read/write tests have lower IOPS, but that is expected.
 
-### Idle test, ZFS
+### Rescue test, ZFS
+
+This test was also performed in rescue mode.
 
 Raw numbers, from the [[job-curie-zfs.log]], converted to MiB/s and
 manually merged:
@@ -796,6 +813,9 @@ This is, therefore, part of my [[services/backup]] services.
 This section documents how an external NVMe enclosure was setup in a
 pool to mirror the datasets from my workstation.
 
+The final setup should include syncoid copying datasets to the backup
+server regularly, but I haven't finished that configuration yet.
+
 ## Partitioning
 
 The above partitioning procedure used `sgdisk`, but I couldn't figure
@@ -1144,17 +1164,12 @@ SMART self-test succeeded.
 - TODO: ship my on .debs? `dkms mkbmdeb zfs/2.0.3` is the magic
   command here. see also [this idea in grml](https://github.com/grml/grml-live/issues/78) and [this packaging
   attempt](https://github.com/ChibaPet/bliss-zfs)
-- TODO: review this [blog post][] which seems to explain a bit the
-  layout behind the installer
 - TODO: document this somewhere: bpool and rpool are both pools and
   datasets. that's pretty confusing, but also very useful because it
   allows for pool-wide recursive snapshots, which are used for the
   backup system
-- TODO: grep for `blog/zfs-migration` elsewhere in the wiki if/when we
-  rename this page
 
 [TRIM]: https://wiki.debian.org/ZFS#TRIM_support
-[blog post]:  https://github.com/djacu/nixos-on-zfs/blob/main/blog/2022-03-24.md
 
 ## fio improvements
 
diff --git a/hardware/tubman.md b/hardware/tubman.md
index ac3f0e52..40232f51 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -52,7 +52,7 @@ was kept install, on a stack of 5 disks (3x~2TB HDD, 2x128GB SSD).
 
 Before the migration from marcos' body to toutatis', a ZFS scrub
 triggered a warning. The drives were inspected for health, this is the
-report (copied from [[blog/zfs-migration]]).
+report (copied from [[blog/2022-11-17-zfs-migration]]).
 
 Here's some SMART stats:
 
@@ -747,7 +747,7 @@ possible to move the system (and only that) to SSD (it's currently on
 2x4TB + 500GB SSD cache).
 
  1. first, partition the new disk (we reuse the disk formatting
-    command used for curie, see [[blog/zfs-migration]]):
+    command used for curie, see [[blog/2022-11-17-zfs-migration]]):
     
         sgdisk --zap-all /dev/sdc
         sgdisk -a1 -n1:24K:+1000K -t1:EF02 /dev/sdc
@@ -1347,7 +1347,7 @@ stuck at a prompt:
 # Other documentation
 
 See [[software/zfs]] for more documentation on ZFS and
-[[blog/zfs-migration]] for another installation and migration
-procedure.
+[[blog/2022-11-17-zfs-migration]] for another installation and
+migration procedure.
 
 [[!tag node]]
diff --git a/software/zfs.md b/software/zfs.md
index 53ef4b18..12ae1076 100644
--- a/software/zfs.md
+++ b/software/zfs.md
@@ -218,7 +218,7 @@ dataset level.
    excellent as always
  * [OpenZFS FAQ][]
  * [OpenZFS: Debian buyllseye root on ZFS][]: excellent documentation,
-   basis for the install procedures in [[blog/zfs-migration]] and
+   basis for the install procedures in [[blog/2022-11-17-zfs-migration]] and
    [[hardware/tubman]]
  * [OpenZFS: Debian buster root on ZFS][]: same, for buster
  * [WIP PR for Bullseye root on ZFS instructions][]: where I

clear a todo
diff --git a/blog/zfs-migration.md b/blog/zfs-migration.md
index 8378c45a..4720494a 100644
--- a/blog/zfs-migration.md
+++ b/blog/zfs-migration.md
@@ -1144,8 +1144,6 @@ SMART self-test succeeded.
 - TODO: ship my on .debs? `dkms mkbmdeb zfs/2.0.3` is the magic
   command here. see also [this idea in grml](https://github.com/grml/grml-live/issues/78) and [this packaging
   attempt](https://github.com/ChibaPet/bliss-zfs)
-- TODO: merge some of this documentation with the [[hardware/tubman]]
-  documentation.
 - TODO: review this [blog post][] which seems to explain a bit the
   layout behind the installer
 - TODO: document this somewhere: bpool and rpool are both pools and
@@ -1410,6 +1408,7 @@ this.
 
 # References
 
-See the [[software/zfs]] documentation for more information about ZFS.
+See the [[software/zfs]] documentation for more information about ZFS,
+and [[hardware/tubman]] for another installation and migration procedure.
 
 [[!tag draft]]
diff --git a/hardware/tubman.md b/hardware/tubman.md
index 751a9060..ac3f0e52 100644
--- a/hardware/tubman.md
+++ b/hardware/tubman.md
@@ -1346,6 +1346,8 @@ stuck at a prompt:
 
 # Other documentation
 
-See [[software/zfs]] for more documentation on ZFS.
+See [[software/zfs]] for more documentation on ZFS and
+[[blog/zfs-migration]] for another installation and migration
+procedure.
 
 [[!tag node]]

conclusions, remove M.2 results
diff --git a/blog/zfs-migration.md b/blog/zfs-migration.md
index 61b3b9bc..8378c45a 100644
--- a/blog/zfs-migration.md
+++ b/blog/zfs-migration.md
@@ -569,20 +569,6 @@ now. It just batches a bunch of `fio` tests, one by one, 60 seconds
 each. It should take about 12 minutes to run, as there are 3 pair of
 tests, read/write, with and without async.
 
-And before I show the results, it should be noted there is a huge
-caveat here The test is done between:
-
- * a WDC WDS500G1B0B-00AS40 SSD, a [WD blue M.2 2280 SSD][] (running
-   mdadm/LUKS/LVM/ext4), that is at least 5 years old, spec'd at
-   560MB/s read, 530MB/s write
-
- * a brand new [WD blue SN550][] drive, which claims to be able to
-   push 2400MB/s read and 1750MB/s write
-
-In practice, I'm going to assume we'll never reach those numbers
-because we're not actually NVMe so the bottleneck isn't the disk
-itself. For our purposes, it might still give us useful results.
-
 My bias, before building, running and analysing those results is that
 ZFS should outperform the traditional stack on writes, but possibly
 not on reads. It's also possible it outperforms it on both, because
@@ -599,46 +585,17 @@ USB drive as well, although I doubt I will find the time to do this.
 
 ## Results
 
-### Non-idle test, mdadm/luks/lvm/ext4
-
-Those tests were done with the above script, in `/home`, while working
-on other things on my workstation, which generally felt sluggish, so I
-assume my work affected the benchmarks greatly.
-
- * 4k blocks, 4GB, 1 process:
-   * read: 21.5MiB/s (22.5MB/s), sync: 20.8MiB/s (21.9MB/s)
-   * write: 139MiB/s (146MB/s), sync: 1118KiB/s (1145kB/s)
- * 64k blocks, 256MB, 16 process:
-   * read: 513MiB/s (537MB/s), sync: 512MiB/s (537MB/s)
-   * write: 160MiB/s (167MB/s), sync: 41.5MiB/s (43.5MB/s)
- * 1m blocks, 16G 1 process:
-   * read: 165MiB/s (173MB/s), sync: 172MiB/s (180MB/s)
-   * write: 74.7MiB/s (78.3MB/s), sync: 38.5MiB/s (40.4MB/s)
-
-### Somewhat idle test, mdadm/luks/lvm/ext4
-
-This test was done while I was away from my workstation. Everything
-was still running, so a bunch of stuff was probably waking up and
-disturbing the test, but it should be more reliable than the above.
-
- * 4k blocks, 4GB, 1 process:
-   * read: 16.8MiB/s (17.7MB/s), sync: 18.9MiB/s (19.8MB/s)
-   * write: 73.8MiB/s (77.3MB/s), sync: 847KiB/s (867kB/s)
- * 64k blocks, 256MB, 16 process:
-   * read: 526MiB/s (552MB/s), sync: 520MiB/s (546MB/s)
-   * write: 98.3MiB/s (103MB/s), sync: 29.6MiB/s (30.0MB/s)
- * 1m blocks, 16G 1 process:
-   * read: 148MiB/s (155MB/s), sync: 162MiB/s (170MB/s)
-   * write: 109MiB/s (114MB/s), sync: 48.6MiB/s (50.0MB/s)
-
-It looks like the 64k test is the one that can max out the SSD, for
-what it's worth. Those results are curiously inconsistent with the
-non-idle test, many tests perform more *poorly* than when the
-workstation was busy, which is troublesome.
-
-Another test was performed while in "rescue" mode but was ultimately
-lost. It's actually still in the old M.2 drive, but I cannot mount
-that device with the external USB controller I have right now.
+All tests were done on [WD blue SN550][] drives, which claims to be
+able to push 2400MB/s read and 1750MB/s write. An extra drive was
+bought to move the LVM setup from a WDC WDS500G1B0B-00AS40 SSD, a [WD
+blue M.2 2280 SSD][] that was at least 5 years old, spec'd at 560MB/s
+read, 530MB/s write. Benchmarks were done on the M.2 SSD drive but
+discarded so that the drive difference is not a factor in the test.
+
+In practice, I'm going to assume we'll never reach those numbers
+because we're not actually NVMe (this is an old workstation!) so the
+bottleneck isn't the disk itself. For our purposes, it might still
+give us useful results.
 
 ### Rescue test, mdadm/luks/lvm/ext4
 
@@ -682,8 +639,8 @@ manually merged:
 | rand4k4g1x--fsync=1     |   76.16  | 19495     |   6.53    | 1673       |
 | rand64k256m16x          | 1882.40  | 30118     |  70.58    | 1129       |
 | rand64k256m16x--fsync=1 | 1865.13  | 29842     |  71.98    | 1151       |
-| rand1m16g1x             |  921.62  |   921     | 102.21    | 102        |
-| rand1m16g1x--fsync=1    |  908.37  |   908     |  64.30    | 64         |
+| rand1m16g1x             |  921.62  |   921     | 102.21    |  102       |
+| rand1m16g1x--fsync=1    |  908.37  |   908     |  64.30    |   64       |
 
 Peaks are at 1.8GiB/s read, also in the 64k job like above, but much
 faster. The write is, as expected, *much* slower at 70MiB/s (compared
@@ -691,6 +648,8 @@ to 1GiB/s!), but it should be noted the sync write doesn't degrade
 performance compared to async writes (although it's still below the
 LVM 300MB/s).
 
+### Conclusions
+
 Really, ZFS has trouble performing in *all* write conditions. The
 random 4k sync write test is the *only* place where ZFS outperforms
 LVM in writes, and barely (7MiB/s vs 3MiB/s). Everywhere else, writes
@@ -702,6 +661,24 @@ you that those numbers are on a bare bones NVMe drive, pretty much as
 fast storage as you can find on this machine. Adding another NVMe
 drive as a cache probably will not improve write performance here.
 
+Still, those are very different results than the [tests performed by
+Salter](https://arstechnica.com/gadgets/2020/05/zfs-versus-raid-eight-ironwolf-disks-two-filesystems-one-winner/) which shows ZFS beating traditional configurations in all
+categories but uncached 4k reads (not writes!). That said, those tests
+are very different from the tests I performed here, where I test
+writes on a *single* disk, not a RAID array, which might explain the
+discrepancy.
+
+Also, note that neither LVM or ZFS manage to reach the 2400MB/s read
+and 1750MB/s write performance specification. ZFS does manage to reach
+82% of the read performance (1973MB/s) and LVM 64% of the write
+performance (1120MB/s). LVM hits 57% of the read performance and ZFS
+hits barely 6% of the write performance.
+
+Overall, I'm a bit disappointed in the ZFS write performance here, I
+must say. Maybe I need to tweak the record size or some other ZFS
+voodoo, but I'll note that I didn't have to do any such configuration
+on the other side to kick ZFS in the pants...
+
 ## Real world experience
 
 This section document not synthetic backups, but actual real world
@@ -877,7 +854,7 @@ Main pool creation is:
 [no unicode normalization]: https://github.com/openzfs/openzfs-docs/pull/306
 [reordered parameters]: https://github.com/openzfs/openzfs-docs/pull/308
 
-## first sync
+## First sync
 
 I used syncoid to copy all pools over to the external device. syncoid
 is a thing that's part of the [sanoid project][] which is

complete zfs vs LVM benchmarks
diff --git a/blog/zfs-migration.md b/blog/zfs-migration.md
index 211726bf..61b3b9bc 100644
--- a/blog/zfs-migration.md
+++ b/blog/zfs-migration.md
@@ -640,17 +640,67 @@ Another test was performed while in "rescue" mode but was ultimately
 lost. It's actually still in the old M.2 drive, but I cannot mount
 that device with the external USB controller I have right now.
 
-### Idle test, mdadm/luks/lvm/ext4
+### Rescue test, mdadm/luks/lvm/ext4
 
-TODO
+Those tests were performed with everything shutdown, after either
+entering the system in rescue mode, or by reaching that target with:
 
-### Idle test, ZFS
+    systemctl rescue
+
+The network might have been started before or after the test as well:
+
+    systemctl start systemd-networkd
+
+So it should be fairly reliable as basically nothing else is running.
+
+Raw numbers, from the [[job-curie-lvm.log]], converted to MiB/s and
+manually merged:
 
-This test was performed while logged out of my main account, running
-the test in a virtual console. So it should be fairly reliable as
-basically nothing else is running.
+| test                    | read I/O | read IOPS | write I/O | write IOPS |
+|-------------------------|----------|-----------|-----------|------------|
+| rand4k4g1x              |   39.27  | 10052     |    212.15 | 54310      |
+| rand4k4g1x--fsync=1     |   39.29  | 10057     |      2.73 | 699        |
+| rand64k256m16x          | 1297.00  | 20751     |   1068.57 | 17097      |
+| rand64k256m16x--fsync=1 | 1290.90  | 20654     |    353.82 | 5661       |
+| rand1m16g1x             |  315.15  | 315       |    563.77 | 563        |
+| rand1m16g1x--fsync=1    |  345.88  | 345       |    157.01 | 157        |
+
+Peaks are at about 20k IOPS and ~1.3GiB/s read, 1GiB/s write in the
+64KB blocks with 16 jobs.
+
+Slowest is the random 4k block sync write at an abysmal 3MB/s and 700
+IOPS The 1MB read/write tests have lower IOPS, but that is expected.
+
+### Idle test, ZFS
 
-TODO
+Raw numbers, from the [[job-curie-zfs.log]], converted to MiB/s and
+manually merged:
+
+| test                    | read I/O | read IOPS | write I/O | write IOPS |
+|-------------------------|----------|-----------|-----------|------------|
+| rand4k4g1x              |   77.20  | 19763     |  27.13    | 6944       |
+| rand4k4g1x--fsync=1     |   76.16  | 19495     |   6.53    | 1673       |
+| rand64k256m16x          | 1882.40  | 30118     |  70.58    | 1129       |
+| rand64k256m16x--fsync=1 | 1865.13  | 29842     |  71.98    | 1151       |
+| rand1m16g1x             |  921.62  |   921     | 102.21    | 102        |
+| rand1m16g1x--fsync=1    |  908.37  |   908     |  64.30    | 64         |
+
+Peaks are at 1.8GiB/s read, also in the 64k job like above, but much
+faster. The write is, as expected, *much* slower at 70MiB/s (compared
+to 1GiB/s!), but it should be noted the sync write doesn't degrade
+performance compared to async writes (although it's still below the
+LVM 300MB/s).
+
+Really, ZFS has trouble performing in *all* write conditions. The
+random 4k sync write test is the *only* place where ZFS outperforms
+LVM in writes, and barely (7MiB/s vs 3MiB/s). Everywhere else, writes
+are much slower, sometimes by an order of magnitude. 
+
+And before some ZFS zealot jumps in talking about the SLOG or some
+other cache that could be added to improved performance, I'll remind
+you that those numbers are on a bare bones NVMe drive, pretty much as
+fast storage as you can find on this machine. Adding another NVMe
+drive as a cache probably will not improve write performance here.
 
 ## Real world experience
 

an option for native emazcs
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 0d656652..582e1d61 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -297,7 +297,9 @@ working port (to GTK3) was completed in 2021, but wasn't merged until
 
 So we'll probably need to wait for Emacs 29 to have native Wayland
 support in Emacs, which, in turn, is unlikely to arrive in time for
-the [Debian bookworm freeze](https://lists.debian.org/debian-devel/2022/03/msg00251.html).
+the [Debian bookworm freeze](https://lists.debian.org/debian-devel/2022/03/msg00251.html). There are, however, [unofficial
+builds](https://silentflame.com/debian/) for both Emacs 28 and 29 provided by [spwhitton](https://spwhitton.name/) which
+may provide native Wayland support.
 
 Still, like many X11 applications, Emacs mostly works fine under
 Xwayland. The clipboard works as expected, for example.

multi monitor works well, better than xorg even
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 7bcaa2ae..0d656652 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -222,10 +222,14 @@ So now I just set that variable in `environment.d` and It Just Works™:
 ### Screen sharing
 
 Out of the box, screen sharing doesn't work until you install
-[xdg-desktop-portal-wlr](https://github.com/emersion/xdg-desktop-portal-wlr/). I had to reboot for the change to take
-effect. Otherwise it shows the usual permission prompt with "Use
-operating system settings" as the only choice and when we accept...
-nothing happens.
+[xdg-desktop-portal-wlr](https://github.com/emersion/xdg-desktop-portal-wlr/) or similar
+(e.g. [xdg-desktop-portal-gnome](https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome) on GNOME). I had to reboot for the
+change to take effect.
+
+Without those tools, it shows the usual permission prompt with "Use
+operating system settings" as the only choice, but when we accept...
+nothing happens. After installing the portals, it actualyl works, and
+works well!
 
 This was tested in Debian bookworm/testing with Firefox ESR 102 and
 Firefox 106.
@@ -236,6 +240,11 @@ it streams *only* [one output](https://github.com/emersion/xdg-desktop-portal-wl
 of the time! See the [screencast compatibility](https://github.com/emersion/xdg-desktop-portal-wlr/wiki/Screencast-Compatibility) for more
 information on what is supposed to work.
 
+This is actually a *huge* improvement over the situation in Xorg,
+where Firefox [can only share a window or all monitors](https://bugzilla.mozilla.org/show_bug.cgi?id=1412333), which led
+me to use Chromium a lot for video-conferencing. With this change, in
+other words, I will not need Chromium for anything anymore, whoohoo!
+
 If [[!debpkg slurp]], [[!debpkg wofi]], or [[!debpkg bemenu]] are
 installed, one of them will be used to pick the monitor to share,
 which effectively acts as some minimal security measure. See
@@ -246,14 +255,10 @@ which effectively acts as some minimal security measure. See
 
 ### Side note: Chrome fails to share a full screen
 
-I actually still use Google Chrome (or, more accurately, Debian's
+I was still using Google Chrome (or, more accurately, Debian's
 Chromium package) for some videoconferencing. It's mainly because
-chromium is the only browser which will allow me to share only one of
-my two monitors, which is extremely useful. 
-
-(Now, it's actually possible I won't need Chromium anymore because
-Firefox under Wayland *might* actually support streaming just a
-monitor, but I haven't tested that yet.)
+Chromium was the only browser which will allow me to share only one of
+my two monitors, which is extremely useful.
 
 To start chrome with the Wayland backend, you need to use:
 
@@ -264,7 +269,11 @@ Wayland. In Sway, it shows a huge gray border around the browser (!!).
 
 It *can* however, do *some* screensharing. Sharing a window and a tab
 seems to work, but sharing a full screen doesn't: it's all
-black. Definitely not ready for prime time.
+black. Definitely not ready for prime time. And since Firefox can do
+the right thing (mostly) under Wayland, I will not need to fight with
+Chromium to work under Wayland.
+
+    apt purge chromium
 
 ## Email: notmuch
 
@@ -735,7 +744,7 @@ See also:
 TODO: `autorandr` conversion... [kanshi][]? see [this service
 file](https://github.com/xdbob/sway-services/blob/master/systemd/kanshi.service). wallutils can also do this, apparently.
 
-### arandr
+### arandr → wdisplays
 
 arandr is not directly part of X, but there's also no cleary
 established equivalent... [arewewaylandyet.com][] refers to a few:
@@ -745,6 +754,9 @@ established equivalent... [arewewaylandyet.com][] refers to a few:
 | [wdisplays][]    | yes       |
 | [nwg-displays][] | no        |
 
+I have tried [wdisplays][] and it Just Works, and well. The UI even
+looks better and more usable than arandr, so another clean win from
+Wayland here.
 
 [wdisplays]: https://github.com/artizirk/wdisplays
 [nwg-displays]: https://github.com/nwg-piotr/nwg-displays

move TODOs, seems like we already had a procecure
diff --git a/blog/zfs-migration.md b/blog/zfs-migration.md
index 5a17a8e9..211726bf 100644
--- a/blog/zfs-migration.md
+++ b/blog/zfs-migration.md
@@ -640,6 +640,18 @@ Another test was performed while in "rescue" mode but was ultimately
 lost. It's actually still in the old M.2 drive, but I cannot mount
 that device with the external USB controller I have right now.
 
+### Idle test, mdadm/luks/lvm/ext4
+
+TODO
+
+### Idle test, ZFS
+
+This test was performed while logged out of my main account, running
+the test in a virtual console. So it should be fairly reliable as
+basically nothing else is running.
+
+TODO
+
 ## Real world experience
 
 This section document not synthetic backups, but actual real world
@@ -943,10 +955,6 @@ Copied the 512GB SSD/M.2 device to *another* 1024GB NVMe/M.2 device:
 
 ... while both over USB, whoohoo 300MB/s!
 
-TODO: Next step is to make a benchmark of LVM vs ZFS, since they have
-(in theory) both the same hardware now (although the LVM copy is
-lagging behind the ZFS one, naturally).
-
 # Monitoring
 
 ZFS should be monitoring your pools regularly. Normally, the [[!debman

note that 6.2 might improve things too
diff --git a/hardware/laptop/framework-12th-gen.md b/hardware/laptop/framework-12th-gen.md
index 0a1b6724..6d9cf3d0 100644
--- a/hardware/laptop/framework-12th-gen.md
+++ b/hardware/laptop/framework-12th-gen.md
@@ -1170,6 +1170,10 @@ management issues will eventually be fixed.
 Note that the upcoming [Ethernet card has a reported 2-8W power usage,
 depending on traffic](https://community.frame.work/t/ethernet-expansion-card-photos-quick-start-guide-benchmarking/22574/4?u=anarcat).
 
+The upcoming 6.2 Linux kernel might also improve battery usage when
+idle, see [this Phoronix article for details](https://www.phoronix.com/news/Lazy-RCU-Likely-For-Linux-6.2), likely in early
+2023.
+
 ### Standby battery usage
 
 I wrote some [[quick hack to evaluate how much power is used during

minimal pipewire docs
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 45eb3c2f..7bcaa2ae 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -945,6 +945,76 @@ to have a `.shenv` that I had to manually source everywhere. The only
 problem with that approach is that it doesn't support conditionals,
 but that's something that's rarely needed.
 
+## Pipewire
+
+This is a whole topic onto itself, but migrating to Wayland also
+involves migrating to [Pipewire][] if you want screen sharing to
+work. That migration is actually something I've wanted to do anyways:
+Pipewire's design seems much better than Pulseaudio, as it folds in
+[JACK](https://jackaudio.org/) features that allow pretty neat tricks.
+
+I first tried this migration in Debian bullseye, and it didn't work
+very well. Ardour would [fail to export tracks](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994208) and I would get
+into weird situations where streams would just drop mid-way. 
+
+A particularly funny incident is when I was in a meeting and I
+couldn't hear my colleagues speak anymore (but they could) and I went
+on blabbering on my own for a solid 5 minutes until I realized what
+was going on. By then, people had tried numerous ways of letting me
+know that something was off, including (apparently) coughing, saying
+"hello?", chat messages, IRC, and so on, until they just gave up and
+left. 
+
+I suspect that was also a Pipewire bug, but it could also have been
+that I muted the tab by error, as I recently learned that clicking on
+the little tiny speaker icon on a tab mutes that tab. Since the tab
+itself can get pretty small when you have lots of them, it's actually
+quite frequently that I mistakenly mute tabs.
+
+Anyways. Point is, I already knew how to make the migration, and I had
+[documented how to make the change in Puppet](https://gitlab.com/anarcat/puppet/-/blob/main/site-modules/profile/manifests/pipewire.pp). It's basically:
+
+    apt install pipewire pipewire-audio-client-libraries pipewire-pulse wireplumber 
+
+Then, as a regular user:
+
+    systemctl --user daemon-reload
+    systemctl --user --now disable pulseaudio.service pulseaudio.socket
+    systemctl --user --now enable pipewire pipewire-pulse
+    systemctl --user mask pulseaudio
+
+An optional (but key, IMHO) configuration you should also make is to
+"switch on connect", which will make your Bluetooth or USB headset
+automatically be the default route for audio, when connected. In
+`~/.config/pipewire/pipewire.conf`:
+
+    context.exec = [
+        { path = "pactl"        args = "load-module module-always-sink" }
+        { path = "pactl"        args = "load-module module-switch-on-connect" }
+        #{ path = "/usr/bin/sh"  args = "~/.config/pipewire/default.pw" }
+    ]
+
+See the excellent — as usual — [Arch wiki](https://wiki.archlinux.org/title/PipeWire#Sound_does_not_automatically_switch_when_connecting_a_new_device) for that trick and more
+information about Pipewire.
+
+So far I'm happy with Pipewire in bookworm, but I've heard mixed
+reports from it. I have high hopes it will become the standard media
+server for Linux in the coming months or years, which is great because
+I've been (rather boldly, I admit) on the record saying [[I don't like
+PulseAudio|blog/2013-02-04-why-i-dont-pulseaudio]].
+
+Rereading this now, I feel it might have been a little unfair, as
+"over-engineered and tries to do too many things at once" applies
+probably even more to Pipewire than PulseAudio (since it also handles
+video dispatching).
+
+That said, I think Pipewire took the right approach by implementing
+*existing* interfaces like Pulseaudio and JACK. That way we're not
+adding a third (or fourth?) way of doing audio in Linux; we're just
+making the server better.
+
+[Pipewire]: https://pipewire.org/
+
 # Improvements over i3
 
 ## Tiling improvements

some phrasing
diff --git a/blog/zfs-migration.md b/blog/zfs-migration.md
index c9da15e6..5a17a8e9 100644
--- a/blog/zfs-migration.md
+++ b/blog/zfs-migration.md
@@ -747,8 +747,15 @@ then you mount the root filesystem and all the others:
 
 # Offsite backup
 
-TODO: explain why I'm doing, and how it works broadly.
-TODO: cross ref with services/backup
+Part of the goal of using ZFS is to simplify and harden backups. I
+wanted to experiment with shorter recovery times — specifically both
+[point in time recovery](https://en.wikipedia.org/wiki/Point-in-time_recovery) objective and [recovery time objective](https://en.wikipedia.org/wiki/Disaster_recovery#Recovery_Time_Objective)
+— and faster incremental backups.
+
+This is, therefore, part of my [[services/backup]] services.
+
+This section documents how an external NVMe enclosure was setup in a
+pool to mirror the datasets from my workstation.
 
 ## Partitioning
 
@@ -924,7 +931,7 @@ Once that's done, export the pools to disconnect the drive:
 [sanoid project]: https://github.com/jimsalterjrs/sanoid
 [tried to fix that with an upstream PR]: https://github.com/jimsalterjrs/sanoid/pull/748
 
-## LVM benchmark
+## Raw disk benchmark
 
 Copied the 512GB SSD/M.2 device to *another* 1024GB NVMe/M.2 device:
 
@@ -936,9 +943,9 @@ Copied the 512GB SSD/M.2 device to *another* 1024GB NVMe/M.2 device:
 
 ... while both over USB, whoohoo 300MB/s!
 
-TODO: Next step is to make a benchmark of LVM vs ZFS, since have (in
-theory) both the same hardware now (although the LVM copy is lagging
-behind the ZFS one, naturally).
+TODO: Next step is to make a benchmark of LVM vs ZFS, since they have
+(in theory) both the same hardware now (although the LVM copy is
+lagging behind the ZFS one, naturally).
 
 # Monitoring
 
@@ -958,7 +965,7 @@ When the scrub runs, if it finds anything it will send an event which
 will get picked up by the `zed` daemon which will then send a
 notification, see below for an example.
 
-TODO: deploy on curie.
+TODO: deploy on curie, if possible (probably not because no RAID)
 TODO: check if it's setup on tubman properly.
 
 [this configuration guide]: https://pieterbakker.com/monitoring-zfs-with-zed/

move ZFS backup docs under zfs
diff --git a/services/backup.mdwn b/services/backup.mdwn
index 3bd6e617..92dad073 100644
--- a/services/backup.mdwn
+++ b/services/backup.mdwn
@@ -591,5 +591,4 @@ Once we figure out git-annex, the following pages need to be updated:
  * [asuran](https://asuran.rs/) - in development
  * [restic](https://restic.net/) - another alternative, slow at purge
  * [bupstash](https://bupstash.io/)
- * ZFS and [simplesnap](https://github.com/jgoerzen/simplesnap), see [Goerzen's ZFS series](https://changelog.complete.org/archives/10186-more-topics-on-store-and-forward-possibly-airgapped-zfs-and-non-zfs-backups-with-nncp) and
-   [[software/zfs]] for my notes
+ * ZFS: see [[software/zfs]] for my notes
diff --git a/software/zfs.md b/software/zfs.md
index 979f606c..53ef4b18 100644
--- a/software/zfs.md
+++ b/software/zfs.md
@@ -137,6 +137,15 @@ It has [no dry run mode](https://github.com/zrepl/zrepl/issues/94).
 The [zfs-auto-snapshot](https://github.com/zfsonlinux/zfs-auto-snapshot/) upstream is [possibly dead](https://github.com/zfsonlinux/zfs-auto-snapshot/issues/104), or at least
 [looking for volunteers](https://github.com/zfsonlinux/zfs-auto-snapshot/issues/117), so probably not an option.
 
+### simplesnap
+
+Goerzen's [simplesnap](https://github.com/jgoerzen/simplesnap) is another option. It's a pair of fairly
+short shell scripts (~600 lines total) that send snapshots to a backup
+host. It's unclear if it supports encryption any better than other
+tools, fairly minimalist.
+
+Packaged in Debian.
+
 # Caveats
 
 ## Empty datasets
@@ -215,6 +224,7 @@ dataset level.
  * [WIP PR for Bullseye root on ZFS instructions][]: where I
    contributed to turn the latter into the former
  * [another ZFS on linux documentation][]
+ * [Goerzen's ZFS series](https://changelog.complete.org/archives/10186-more-topics-on-store-and-forward-possibly-airgapped-zfs-and-non-zfs-backups-with-nncp)
 
 [Debian wiki page]: https://wiki.debian.org/ZFS
 [Arch wiki page]: https://wiki.archlinux.org/title/ZFS

wayland desktop sharing uses slurp if available to pick the screen
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index f5c6fe2a..45eb3c2f 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -236,11 +236,10 @@ it streams *only* [one output](https://github.com/emersion/xdg-desktop-portal-wl
 of the time! See the [screencast compatibility](https://github.com/emersion/xdg-desktop-portal-wlr/wiki/Screencast-Compatibility) for more
 information on what is supposed to work.
 
-TODO: setting a `chooser_cmd` might allow us to pick the output to
-share, see [xdg-desktop-portal-wlr(1)](https://manpages.debian.org/xdg-desktop-portal-wlr). This could double as a
-security measure, to make sure the user accepts a screen sharing
-request. That might also, at least in theory, allow us to stream only
-a window or square.
+If [[!debpkg slurp]], [[!debpkg wofi]], or [[!debpkg bemenu]] are
+installed, one of them will be used to pick the monitor to share,
+which effectively acts as some minimal security measure. See
+[xdg-desktop-portal-wlr(1)](https://manpages.debian.org/xdg-desktop-portal-wlr) for how to configure that.
 
 [environment.d(5)]: https://manpages.debian.org/environment.d
 [systemd.environment-generator(7)]: https://manpages.debian.org/systemd.environment-generator

browserpass alternative
diff --git a/software/desktop/firefox.mdwn b/software/desktop/firefox.mdwn
index 3b3e1906..5e79890c 100644
--- a/software/desktop/firefox.mdwn
+++ b/software/desktop/firefox.mdwn
@@ -26,7 +26,8 @@ I have those extensions installed and use them very frequently:
  * [browserpass-ce](https://addons.mozilla.org/en-US/firefox/addon/browserpass-ce/) ([[!debpkg webext-browserpass desc="debian
    package"]], [source](https://github.com/browserpass/browserpass)) - super fast access to my passwords. use
    some magic mumble-jumble message passing thing which feels a bit
-   creepy.
+   creepy. possible alternative: [passff](https://github.com/passff/passff#readme), no Debian package,
+   [872773](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872773).
  * [Cookie AutoDelete](https://addons.mozilla.org/en-US/firefox/addon/cookie-autodelete/) (no Debian package, [908285](http://bugs.debian.org/908285),
    [source](https://github.com/Cookie-AutoDelete/Cookie-AutoDelete)) - clear long-term identities for all sites except a
    few

fix link to wayland
diff --git a/hardware/laptop/framework-12th-gen.md b/hardware/laptop/framework-12th-gen.md
index 14ad494e..0a1b6724 100644
--- a/hardware/laptop/framework-12th-gen.md
+++ b/hardware/laptop/framework-12th-gen.md
@@ -1477,12 +1477,12 @@ When running from the base session, I would get this instead:
     compiz (core) - Error: Couldn't load plugin 'ccp'
     compiz (core) - Error: Couldn't load plugin 'ccp'
 
-It's also possible that a Wayland environment might do the right thing
-here as well, but I'm [[software/desktop/wayland|not switching to
-wayland just yet]].
-
 Thanks to [EmanueleRocca](https://wiki.debian.org/EmanueleRocca) for figuring all that out. See also [this
 discussion about power management on the Framework forum](https://community.frame.work/t/12th-gen-power-management-on-linux/21330).
+
+Note that Wayland environments do not require any special
+configuration here and actually work better, see my [Wayland migration
+notes](/software/desktop/wayland) for details.
 </div>
 
 <span /><div class="note">

update todos
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index e926743c..f5c6fe2a 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -601,7 +601,7 @@ packaged in Debian.
 
 One has to wonder how this works while keeping the "between app
 security" that Wayland promises, however... Would installing such a
-program make my system less secure? TODO: To be investigated.
+program make my system less secure?
 
 Many other options are available, see the [awesome Wayland
 screencasting list](https://github.com/natpen/awesome-wayland#screencasting).
@@ -733,7 +733,6 @@ See also:
  * <https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway>
  * <https://github.com/swaywm/sway/wiki/i3-Migration-Guide>
 
-TODO: see also the pubpaste section for xdotool
 TODO: `autorandr` conversion... [kanshi][]? see [this service
 file](https://github.com/xdbob/sway-services/blob/master/systemd/kanshi.service). wallutils can also do this, apparently.
 

update: i did try foot, and it's great
diff --git a/blog/2022-09-19-wayland-terminal-emulators.md b/blog/2022-09-19-wayland-terminal-emulators.md
index 7c3dbe97..7f0a682d 100644
--- a/blog/2022-09-19-wayland-terminal-emulators.md
+++ b/blog/2022-09-19-wayland-terminal-emulators.md
@@ -189,7 +189,8 @@ One major problem with foot is that it's yet another terminfo
 entry. They did make it into ncurses (patch [2021-07-31](https://invisible-island.net/ncurses/NEWS.html#index-t20210731)) but only
 after Debian bullseye stable was released. So expect some weird
 compatibility issues when connecting to any other system that is older
-or the same as stable (!).
+or the same as stable (!). Thankfully, there is a `foot-terminfo`
+package that is available starting from Debian bullseye.
 
 One question mark with all Wayland terminals, and Foot in particular,
 is how much latency they introduce in the rendering pipeline. The
@@ -204,4 +205,10 @@ xterm still. Happy to hear ideas in the comments.
 
 [Stay tuned for more happy days](https://www.youtube.com/watch?v=kemivUKb4f4).
 
+Update: a few months after this article was written, I did switch a
+laptop to Wayland, and as part of that migration, adopted foot. It's
+great, and latency is barely noticeable. I recommend people try it out
+when they switch to Wayland, and, inversely, try out Wayland if only
+to try out Foot, it's a great terminal emulator.
+
 [[!tag debian-planet review terminals wayland]]
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index f325dbaf..e926743c 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -348,8 +348,6 @@ I'm still not happy with *any* of them.
 This is such a big topic that I actually have an [[entire blog post
 specifically about this|blog/2022-09-19-wayland-terminal-emulators]].
 
-TODO: update said blog post
-
 For starters, using xterm under Xwayland works well enough, although
 the font scaling makes things look a bit too fuzzy.
 

talk about the security model
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 0ac5543b..f325dbaf 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -996,4 +996,42 @@ Another way to see what is using Wayland in Sway is with the command:
 [arewewaylandyet.com]: https://arewewaylandyet.com/
 [hacktivist.me notes]: https://hacktivis.me/notes/pure-wayland.shtml
 
+# Conclusion
+
+In general, this took me a long time, but it mostly works. The tray
+icon situation is pretty frustrating, but there's a workaround and I
+have high hopes it will eventually fix itself. I'm also actually
+worried about the DisplayLink support because I eventually *want* to
+be using this, but hopefully that's another thing that will hopefully
+fix itself before I need it.
+
+## A word on the security model
+
+I'm kind of worried about all the hacks that have been added to
+Wayland just to make things work. Pretty much everywhere we need to,
+we punched a hole in the security model:
+
+ * windows can spy on each other (although [xdg-desktop-portal-wlr][]
+   might offer confirmation, optionally?)
+ * windows can type over each other (through wtype)
+ * windows can overlay on top of each other
+
+I think the only thing that's not possible in Wayland (yet?) is
+one application overwriting another application's display, and even
+there, things like [gammastep][] show you can at least alter the
+display somehow.
+
+[Wikipedia describes the security properties of Wayland](https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Comparison_with_other_window_systems) as it "isolates
+the input and output of every window, achieving confidentiality,
+integrity and availability for both." I'm not sure those of Wayland
+are actually realized in the actual implementation, because of all
+those holes punched in the design.
+
+It does offer a better basis to implement such a system, however, but
+it feels like the Linux applications security model lacks critical
+ideas like the user approving "yes, this application can share my
+screen right now, or always". Applications themselves *might* have
+these kind of dialogs enabled, but it's mostly absent, and that is
+worrisome.
+
 TODO: tags, publish as a blog?

xdotool not an issue
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 05df5ce8..0ac5543b 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -402,7 +402,7 @@ problems with foot, or any other terminal than xterm, for that matter.
 
 The [foot wiki](https://codeberg.org/dnkl/foot/wiki) has good troubleshooting instructions as well.
 
-## Launcher: rofi → rofi? xdotool a blocker
+## Launcher: rofi → rofi??
 
 rofi does [not support Wayland](https://github.com/davatorium/rofi/issues/446). There was a [rather disgraceful
 battle in the pull request](https://github.com/davatorium/rofi/pull/1139) that led to the creation of a fork
@@ -445,8 +445,10 @@ the idea that one app cannot send keystrokes to another. But it seems
 there *are* actually alternatives to this, like [wtype][] or
 [ydotool](https://github.com/ReimuNotMoe/ydotool), the latter which requires root access. [wl-ime-type][]
 does that through the `input-method-unstable-v2` protocol ([sample
-emoji picker][], but is not packaged in Debian. So who knows how well
-any of that actually works...
+emoji picker][], but is not packaged in Debian.
+
+As it turns out, [wtype][] just works as expected, and fixing this was
+basically a [two-line patch](https://gitlab.com/anarcat/scripts/-/commit/3e8925e7f4257b44eb527bf7cb8f6d8687e9ed3b).
 
 The other problem is that I actually heavily modified rofi. I use
 "modis" which are not actually implemented in wofi *or* tofi, so I'm
@@ -455,10 +457,10 @@ wayland fork... It's really too bad that fork isn't being
 reintegrated...
 
 For now, I'm actually still using rofi under Xwayland. The main
-downside is that fonts are fuzzy, but it otherwise works okay (again
-with the caveat that I cannot auto-type passwords).
+downside is that fonts are fuzzy, but it otherwise just works.
 
-TODO: consider [wlogout](https://github.com/ArtsyMacaw/wlogout) as a partial replacement as well.
+Note that [wlogout](https://github.com/ArtsyMacaw/wlogout) could be a partial replacement (just for the
+"power menu").
 
 [wtype]: https://github.com/atx/wtype
 [alfred]: https://github.com/albertlauncher/albert

document my problems with geeqie
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 364dbce7..05df5ce8 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -494,6 +494,11 @@ Wayland switch will just make add impossible things on top of the
 things I already find irritating (Geeqie doesn't support copy-pasting
 images).
 
+In practice, Geeqie doesn't seem to work so well under Wayland. The
+fonts are fuzzy and the thumbnail preview just doesn't work anymore
+(filed as [Debian bug 1024092](https://bugs.debian.org/1024092)). It seems it also has [problems
+with scaling](https://github.com/BestImageViewer/geeqie/issues/833).
+
 Alternatives:
 
  * [gwenview](https://invent.kde.org/graphics/gwenview): KDE viewer, in Debian

pubpaste fixed
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 21068426..364dbce7 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -562,7 +562,7 @@ In the end, I am just using `swayidle` with a configuration based on
 Interestingly, damjan also has a [service for swaylock](https://github.com/gdamjan/sway-setup/blob/main/systemd/user/swaylock.service) itself,
 although it's not clear to me what its purpose is...
 
-## Screenshot: maim → grim, pubpaste a blocker
+## Screenshot: maim → grim, pubpaste
 
 I'm a heavy user of [maim](https://github.com/naelstrof/maim) (and a package uploader in Debian). It
 looks like the direct replacement to maim (and [slop](https://tracker.debian.org/pkg/slop)) is [grim](https://sr.ht/~emersion/grim/)
@@ -574,11 +574,13 @@ See also [awesome-wayland screenshots](https://github.com/natpen/awesome-wayland
 there are many, including X11 tools like [Flameshot](https://github.com/flameshot-org/flameshot) that also
 support Wayland.
 
-One key problem here is that I have my own screenshot / pastebin
-software which will need an update for Wayland as well, see
-[pubpaste](https://gitlab.com/anarcat/pubpaste).
-
-TODO: add Wayland support for pubpaste (grim and wl-clipboard, basically)
+One key problem here was that I have my own screenshot / pastebin
+software which will needed an update for Wayland as well. That,
+thankfully, meant actually cleaning up a lot of horrible code that
+involved calling xterm and xmessage for user interaction. Now,
+[pubpaste](https://gitlab.com/anarcat/pubpaste) uses GTK for prompts and looks much better. (And before
+anyone freaks out, I already had to use GTK for proper clipboard
+support, so this isn't much of a stretch...)
 
 ## Screen recorder: simplescreenrecorder → wf-recorder
 

more software alternatives
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 81b0fec6..21068426 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -271,6 +271,10 @@ black. Definitely not ready for prime time.
 
 See Emacs, below.
 
+## File manager: thunar
+
+Unchanged.
+
 ## News: feed2exec, gnus
 
 See Email, above, or Emacs in Editor, below.
@@ -324,6 +328,15 @@ Sept. 2022) list the following alternatives:
 I configured `gammastep` with a simple [[gammastep.service]] file
 associated with the [[sway-session.target]].
 
+## Display manager: lightdm → gdm3
+
+Switched because lightdm failed to start sway. TODO: try lightdm
+again, see also those alternatives:
+
+ * [lightdm elephant greeter](https://github.com/max-moser/lightdm-elephant-greeter)
+ * [greetd](https://sr.ht/~kennylevinsen/greetd/) and [QtGreet](https://gitlab.com/marcusbritanicus/QtGreet)
+ * [sddm](https://github.com/sddm/sddm): KDE's default
+
 ## Terminal: xterm → foot
 
 One of the biggest question mark in this transition was what to do
@@ -445,6 +458,8 @@ For now, I'm actually still using rofi under Xwayland. The main
 downside is that fonts are fuzzy, but it otherwise works okay (again
 with the caveat that I cannot auto-type passwords).
 
+TODO: consider [wlogout](https://github.com/ArtsyMacaw/wlogout) as a partial replacement as well.
+
 [wtype]: https://github.com/atx/wtype
 [alfred]: https://github.com/albertlauncher/albert
 [bemenu]: https://github.com/Cloudef/bemenu
@@ -501,6 +516,21 @@ behind).
 
 So for now I'm still grumpily using Geeqie.
 
+## Media player: mpv, gmpc / sublime
+
+This is basically unchanged. `mpv` seems to work fine under Wayland,
+better than Xorg on my new laptop (as mentioned in the introduction),
+and that before the version which [improves Wayland support
+significantly](https://www.phoronix.com/news/MPV-0.35-Released), by bringing native Pipewire support and DMA-BUF
+support.
+
+[gmpc](https://tracker.debian.org/pkg/gmpc) is more of a problem, mainly because it is abandoned. See
+[[blog/2022-08-22-gmpc-alternatives]] for the full discussion, one of
+the alternatives there will likely support Wayland.
+
+Finally, I might just switch to [sublime-music](https://gitlab.com/sublime-music/sublime-music) instead... In any
+case, not many changes here, thankfully.
+
 ## Screensaver: xsecurelock → swaylock
 
 I was previously using xss-lock and xsecurelock as a screensaver, with
@@ -956,3 +986,5 @@ Another way to see what is using Wayland in Sway is with the command:
 [awesome-wayland]: https://github.com/natpen/awesome-wayland
 [arewewaylandyet.com]: https://arewewaylandyet.com/
 [hacktivist.me notes]: https://hacktivis.me/notes/pure-wayland.shtml
+
+TODO: tags, publish as a blog?

finalize edit on wayland article
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index f81e8de9..81b0fec6 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -157,6 +157,8 @@ actually a lot) were *all* **Wayland-specific** changes, not
 *Sway-specific* changes. For example, use `brightnessctl` instead of
 `xbacklight` to change the backlight levels.
 
+See a copy of my full [[sway/config|config]] for details.
+
 ## Status bar: py3status
 
 I have invested quite a bit of effort in setting up my status bar with
@@ -275,22 +277,23 @@ See Email, above, or Emacs in Editor, below.
 
 ## Editor: Emacs okay-ish
 
-TODO: reviewed up to here.
-
 Emacs is being actively ported to Wayland. According to [this LWN
 article](https://lwn.net/Articles/843896/), the first (partial, to Cairo) port was done in 2014 and a
 working port (to GTK3) was completed in 2021, but wasn't merged until
-[late 2021](https://batsov.com/articles/2021/12/19/building-emacs-from-source-with-pgtk/), that is: after [Emacs 28 was released](https://www.gnu.org/savannah-checkouts/gnu/emacs/emacs.html#Releases) (April
-2022). So we'll probably need to wait for Emacs 29 to have native
-support there.
+[late 2021](https://batsov.com/articles/2021/12/19/building-emacs-from-source-with-pgtk/). That is: after [Emacs 28 was released](https://www.gnu.org/savannah-checkouts/gnu/emacs/emacs.html#Releases) (April
+2022). 
 
-Still, like many X11 applications, Emacs will probably work fine under
-Xwayland anyways. The clipboard works, at least, and as expected.
+So we'll probably need to wait for Emacs 29 to have native Wayland
+support in Emacs, which, in turn, is unlikely to arrive in time for
+the [Debian bookworm freeze](https://lists.debian.org/debian-devel/2022/03/msg00251.html).
+
+Still, like many X11 applications, Emacs mostly works fine under
+Xwayland. The clipboard works as expected, for example.
 
 Scaling is a bit of an issue: fonts look fuzzy.
 
 I have heard anecdotal evidence of hard lockups with Emacs running
-under Xwayland as well.
+under Xwayland as well, but haven't experienced any problem so far.
 
 TODO: look again at Wayland in Emacs 29.
 
@@ -298,13 +301,13 @@ TODO: look again at Wayland in Emacs 29.
 
 Mostly irrelevant, as I do not use a GUI.
 
-## Color theme: srcery, redshift → gammastep?
+## Color theme: srcery, redshift → gammastep
 
-Srcery could remain as a color theme, in general.
+I am keeping [Srcery](https://srcery-colors.github.io/) as a color theme, in general.
 
 Redshift is another story: it has [no support for Wayland](https://github.com/jonls/redshift/issues/55) out of
-the box, but it's possible to apply a hack on the tty before
-starting Wayland, with:
+the box, but it's apparently possible to apply a hack on the TTY
+before starting Wayland, with:
 
     redshift -m drm -PO 3000
 
@@ -318,33 +321,39 @@ Sept. 2022) list the following alternatives:
  * [wl-gammaray](https://github.com/jeremija/wl-gammarelay): fork of gammastep, runs as a DBUS service
  * [wlsunset](https://git.sr.ht/~kennylevinsen/wlsunset): [WNPP](http://bugs.debian.org/992729)
 
-I configured `gammastep` with a simple `gammastep.service` file
-associated with the `sway-session.target`.
+I configured `gammastep` with a simple [[gammastep.service]] file
+associated with the [[sway-session.target]].
 
-## Terminal: xterm → foot?
+## Terminal: xterm → foot
 
-One of the biggest question mark in this transition is what to do
-about Xterm. After writing two articles about terminal emulators as a
-professional journalist, decades of working on the terminal, and
-probably using dozens of different terminal emulators, I'm still not
-happy with *any* of them.
+One of the biggest question mark in this transition was what to do
+about Xterm. After writing [two](https://anarc.at/blog/2018-04-12-terminal-emulators-1/) [articles](https://anarc.at/blog/2018-05-04-terminal-emulators-2/) about terminal
+emulators as a professional journalist, decades of working on the
+terminal, and probably using dozens of different terminal emulators,
+I'm still not happy with *any* of them.
 
 This is such a big topic that I actually have an [[entire blog post
 specifically about this|blog/2022-09-19-wayland-terminal-emulators]].
 
-For now, using xterm under Xwayland works well enough, although the
-font scaling makes things look a bit too fuzzy. 
+TODO: update said blog post
+
+For starters, using xterm under Xwayland works well enough, although
+the font scaling makes things look a bit too fuzzy.
 
-I have also tried foot: it ... just works? Fonts are certainly much
-crisper than Xterm and Emacs. URLs are not clickable but the URL
-selector (<kbd>control-shift-u</kbd>) is just plain awesome. The
-word-wrapping is excellent, it doesn't lose one bit. Copy-paste
-works. True colors work. Emojis are nicely sized and colored. Font
-resize works. There's even scrollback search
+I have also tried foot: it ... just works!
+
+Fonts are much crisper than Xterm and Emacs. URLs are not clickable
+but the URL selector (<kbd>control-shift-u</kbd>) is just plain
+awesome (think "[vimperator](https://en.wikipedia.org/wiki/Vimperator)" for the terminal). 
+
+Copy-paste works. True colors work. The word-wrapping is excellent: it
+doesn't lose one byte. Emojis are nicely sized and colored. Font
+resize works. There's even scroll back search
 (<kbd>control-shift-r</kbd>).
 
-I feel like switching to Wayland just for this little goodie, but I
-need to try it for longer to really be sure.
+Foot went from a question mark to being a reason to switch to Wayland,
+just for this little goodie, which says a lot about the quality of
+that software.
 
 The selection clicks are a not quite what I would expect though. In
 rxvt and others, you have the following patterns:
@@ -356,35 +365,44 @@ rxvt and others, you have the following patterns:
 
 I particularly find the "select quotes" bit useful. It seems like foot
 just supports double and triple clicks, with word and line
-selected. You can select a rectangle with square, and it correctly
-extends the selection word-wise with right click if double-click was
-first used.
+selected. You can select a rectangle with <kbd>control</kbd>,. It
+correctly extends the selection word-wise with right click if
+double-click was first used.
 
-Another problem with foot is that it's a new terminal, with its own
+One major problem with Foot is that it's a new terminal, with its own
 [termcap](https://en.wikipedia.org/wiki/Termcap) entry. Support for foot was added to ncurses in the
 [20210731](https://invisible-island.net/ncurses/NEWS.html#index-t20210731) release, which was shipped *after* the current Debian
 stable release (Debian bullseye, which ships 6.2+20201114-2). A
-workaround to this problem is to install the `foot-terminfo` package
-on the remote host, which *is* available in Debian stable. This should
-eventually resolve itself, as Debian bookworm has a newer
+workaround for this problem is to install the `foot-terminfo` package
+on the remote host, which *is* available in Debian stable. 
+
+This should eventually resolve itself, as Debian bookworm has a newer
 version. Note that some corrections were also shipped in the
 [20211113](https://invisible-island.net/ncurses/NEWS.html#index-t20211113) release, but that is also shipped in Debian bookworm.
 
+That said, I am almost certain I will have to revert back to xterm
+under Xwayland at some point in the future. Back when I was using
+GNOME Terminal, it would mostly work for everything until I had to use
+the serial console on a (HP ProCurve) network switch, which have a
+fancy [TUI](https://en.wikipedia.org/wiki/Text-based_user_interface) that was basically unusable there. I fully expect such
+problems with foot, or any other terminal than xterm, for that matter.
+
 The [foot wiki](https://codeberg.org/dnkl/foot/wiki) has good troubleshooting instructions as well.
 
 ## Launcher: rofi → rofi? xdotool a blocker
 
 rofi does [not support Wayland](https://github.com/davatorium/rofi/issues/446). There was a [rather disgraceful
 battle in the pull request](https://github.com/davatorium/rofi/pull/1139) that led to the creation of a fork
-([lbonn/rofi](https://github.com/lbonn/rofi)), so it's unclear how that will turn out. Given how
-relatively trivial that problem is, there is of course a multitude of
-options:
+([lbonn/rofi](https://github.com/lbonn/rofi)), so it's unclear how that will turn out. 
+
+Given how relatively trivial problem space is, there is of course a
+profusion of options:
 
 | Tool                    | In Debian      | Notes                                                                    |
 |-------------------------|----------------|--------------------------------------------------------------------------|
 | [alfred][]              | yes            | general launcher/assistant tool                                          |
 | [bemenu][]              | yes, bookworm+ | inspired by dmenu                                                        |
-| [cerebro][]             | no             | Javascript ... uh... thing debian                                        |
+| [cerebro][]             | no             | Javascript ... uh... thing                                               |
 | [dmenu-wl][]            | no             | fork of [dmenu][], straight port to Wayland                              |
 | [Fuzzel][]              | [ITP 982140][] | dmenu/drun replacement, app icon overlay                                 |
 | [gmenu][]               | no             | drun replacement, with app icons                                         |
@@ -393,17 +411,17 @@ options:
 | [mauncher][]            | no             | dmenu/drun replacement, math                                             |
 | [nwg-launchers][]       | no             | dmenu/drun replacement, JSON config, app icons, [nwg-shell project][]    |
 | [Onagre][]              | no             | rofi/alfred inspired, multiple plugins, Rust                             |
-| [πmenu][]               | no             | dmenu/run rewrite                                                        |
+| [πmenu][]               | no             | dmenu/drun rewrite                                                       |
 | [Rofi (lbonn's fork)][] | no             | see above                                                                |
-| [sirula][]              | no             | .desktop based app launcher                                              |
+| [sirula][]              | no             | `.desktop` based app launcher                                            |
 | [Ulauncher][]           | [ITP 949358][] | generic launcher like Onagre/rofi/alfred, might be overkill              |
-| [tofi][]                | yes, bookworm+ |                                                                          |
+| [tofi][]                | yes, bookworm+ | dmenu/drun replacement, C                                                |
 | [wmenu][]               | no             | fork of dmenu-wl, but mostly a rewrite                                   |
-| [Wofi][]                | yes            | rofi rewrite                                                             |
-| [yofi][]                | no             | dmenu/drun replacement                                                   |
+| [Wofi][]                | yes            | dmenu/drun replacement, not actively maintained                          |
+| [yofi][]                | no             | dmenu/drun replacement, Rust                                             |
 
 The above list comes partly from <https://arewewaylandyet.com/> and
-[awesome-wayland](https://github.com/natpen/awesome-wayland).
+[awesome-wayland](https://github.com/natpen/awesome-wayland). It is likely incomplete.
 
 I have [read some good things][artemis] about bemenu, fuzzel, and wofi.

(Diff truncated)
start edit
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 4b1de583..f81e8de9 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -108,19 +108,62 @@ Wayland fixed all of this.
 
 [artemis]: https://artemis.sh/2022/09/18/wayland-from-an-x-apologist.html
 
-# Window manager: i3 → sway
+# Wayland equivalents
 
-This seems like kind of a no-brainer. [Sway](http://swaywm.org/) is around, it's
-feature-complete, and it's in Debian. Presumably, one can probably
-just reuse their i3 config directly as well?
+This section documents each tool I have picked as an alternative to
+the current Xorg tool I am using for the task at hand. It also touches
+on other alternatives and how the tool was configured.
+
+Note that this list is based on the series of tools I use in
+[[software/desktop]].
+
+TODO: update [[software/desktop]] with the following when done,
+possibly moving old configs to a [[software/desktop/xorg]] archive.
 
-# Status bar: py3status
+## Window manager: i3 → sway
+
+This seems like kind of a no-brainer. [Sway](http://swaywm.org/) is around, it's
+feature-complete, and it's in Debian.
+
+I'm a bit worried about the "Drew DeVault community", to be
+honest. There's a certain aggressiveness in the community I don't like
+so much; at least an open hostility towards more modern UNIX tools
+like containers and systemd that make it hard to do my work while
+interacting with that community.
+
+I'm also concern about the lack of unit tests and user manual for
+Sway. The [i3 window manager](https://i3wm.org/) has been designed by a fellow
+(ex-)Debian developer I have a lot of respect for ([Michael
+Stapelberg](https://michael.stapelberg.ch/)), partly because of i3 itself, but also working with
+him on [other projects](https://manpages.debian.org). Beyond the characters, i3 has a [user
+guide](https://i3wm.org/docs/userguide.html), a [code of conduct](https://i3wm.org/conduct.html), and [lots more
+documentation](https://i3wm.org/docs/). It has a [test suite](https://github.com/i3/i3/tree/next/testcases).
+
+Sway has... manual pages, with the homepage just telling users to use
+`man -k sway` to find what they need. I don't think we need that kind
+of elitism in our communities, to put this bluntly.
+
+But let's put that aside: Sway is still a no-brainer. It's the easiest
+thing to migrate to, because it's *mostly* compatible with i3. I had
+to immediately fix those resources to get a minimal session going:
+
+| i3                   | Sway                     | note                                  |
+|----------------------|--------------------------|---------------------------------------|
+| `set_from_resources` | `set`                    | no support for X resources, naturally |
+| `new_window pixel 1` | `default_border pixel 1` | actually supported in i3 as well      |
+
+That's it. *All* of the other changes I had to do (and there were
+actually a lot) were *all* **Wayland-specific** changes, not
+*Sway-specific* changes. For example, use `brightnessctl` instead of
+`xbacklight` to change the backlight levels.
+
+## Status bar: py3status
 
 I have invested quite a bit of effort in setting up my status bar with
-[py3status](https://py3status.readthedocs.io/). It supports Sway directly, and does not actually
-require any change.
+[py3status](https://py3status.readthedocs.io/). It supports Sway directly, and did not actually
+require any change when migrating to Wayland. Awesome.
 
-# Web browser: Firefox
+## Web browser: Firefox
 
 Firefox has had support for Wayland for a while now, with the team
 [enabling it by default in nightlies around January 2022](https://www.phoronix.com/news/Firefox-Nightly-Wayland-Rolling). It's
@@ -129,7 +172,13 @@ report](https://bugzilla.mozilla.org/show_bug.cgi?id=635134) is still open and i
 depends on 76 open bugs, it was opened *twelve* (2010) years ago, and
 it's still getting daily updates (mostly linking to other tickets).
 
-## How to enable it
+[Firefox 106](https://www.mozilla.org/en-US/firefox/106.0/releasenotes/) presumably shipped with "Better screen sharing for
+Windows and Linux Wayland users", but I couldn't quite figure out what
+those were.
+
+TL;DR: `echo MOZ_ENABLE_WAYLAND=1 >> ~/.config/environment.d/firefox.conf && apt install xdg-desktop-portal-wlr`
+
+### How to enable it
 
 Firefox depends on this silly variable to start correctly under
 Wayland (otherwise it starts inside Xwayland and looks fuzzy and fails
@@ -168,12 +217,12 @@ So now I just set that variable in `environment.d` and It Just Works™:
 
     MOZ_ENABLE_WAYLAND=1
 
-## Screen sharing
+### Screen sharing
 
 Out of the box, screen sharing doesn't work until you install
 [xdg-desktop-portal-wlr](https://github.com/emersion/xdg-desktop-portal-wlr/). I had to reboot for the change to take
 effect. Otherwise it shows the usual permission prompt with "Use
-operating system settings" as the only choice and when we accept,
+operating system settings" as the only choice and when we accept...
 nothing happens.
 
 This was tested in Debian bookworm/testing with Firefox ESR 102 and
@@ -194,33 +243,39 @@ a window or square.
 [environment.d(5)]: https://manpages.debian.org/environment.d
 [systemd.environment-generator(7)]: https://manpages.debian.org/systemd.environment-generator
 
-## Chrome fails to share a full screen
+### Side note: Chrome fails to share a full screen
 
 I actually still use Google Chrome (or, more accurately, Debian's
 Chromium package) for some videoconferencing. It's mainly because
 chromium is the only browser which will allow me to share only one of
-my two monitors, which is extremely useful.
+my two monitors, which is extremely useful. 
+
+(Now, it's actually possible I won't need Chromium anymore because
+Firefox under Wayland *might* actually support streaming just a
+monitor, but I haven't tested that yet.)
 
 To start chrome with the Wayland backend, you need to use:
 
     chromium  -enable-features=UseOzonePlatform -ozone-platform=wayland
 
-Unfortunately, chrome doesn't work as well as one would expect under
-Wayland. In Sway, it shows a huge gray border around the browser. It
-*can* however, do *some* screensharing. Sharing a window and a tab
+Unfortunately, Chromium doesn't work as well as one would expect under
+Wayland. In Sway, it shows a huge gray border around the browser (!!).
+
+It *can* however, do *some* screensharing. Sharing a window and a tab
 seems to work, but sharing a full screen doesn't: it's all
-black. Definitely not ready for prime time, but it might actually work
-to share one monitor at a time.
+black. Definitely not ready for prime time.
 
-# Email: notmuch
+## Email: notmuch
 
 See Emacs, below.
 
-# News: feed2exec, gnus
+## News: feed2exec, gnus
 
 See Email, above, or Emacs in Editor, below.
 
-# Editor: Emacs okay-ish
+## Editor: Emacs okay-ish
+
+TODO: reviewed up to here.
 
 Emacs is being actively ported to Wayland. According to [this LWN
 article](https://lwn.net/Articles/843896/), the first (partial, to Cairo) port was done in 2014 and a
@@ -239,11 +294,11 @@ under Xwayland as well.
 
 TODO: look again at Wayland in Emacs 29.
 
-# Backups: borg
+## Backups: borg
 
 Mostly irrelevant, as I do not use a GUI.
 
-# Color theme: srcery, redshift → gammastep?
+## Color theme: srcery, redshift → gammastep?
 
 Srcery could remain as a color theme, in general.
 
@@ -266,7 +321,7 @@ Sept. 2022) list the following alternatives:
 I configured `gammastep` with a simple `gammastep.service` file
 associated with the `sway-session.target`.
 
-# Terminal: xterm → foot?
+## Terminal: xterm → foot?
 
 One of the biggest question mark in this transition is what to do
 about Xterm. After writing two articles about terminal emulators as a
@@ -317,7 +372,7 @@ version. Note that some corrections were also shipped in the
 
 The [foot wiki](https://codeberg.org/dnkl/foot/wiki) has good troubleshooting instructions as well.
 
-# Launcher: rofi → rofi? xdotool a blocker
+## Launcher: rofi → rofi? xdotool a blocker
 
 rofi does [not support Wayland](https://github.com/davatorium/rofi/issues/446). There was a [rather disgraceful
 battle in the pull request](https://github.com/davatorium/rofi/pull/1139) that led to the creation of a fork
@@ -396,7 +451,7 @@ reintegrated...
 [wl-ime-type]: https://git.sr.ht/~emersion/wl-ime-type
 [sample emoji picker]: https://git.sr.ht/~emersion/dotfiles/tree/master/item/bin/emoji-menu
 
-# Image viewers: geeqie → ?
+## Image viewers: geeqie → ?
 
 I'm not very happy with geeqie in the first place, and I suspect the
 Wayland switch will just make irritating things (no image copy-paste)
@@ -415,7 +470,7 @@ Alternatives:
 
 TODO: pick an alternative to geeqie, see if nomacs can be fixed?
 

(Diff truncated)
rebuild lead and "why"
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index c9b34d2c..4b1de583 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -1,42 +1,30 @@
-I do not yet use Wayland, mostly because switching away from Xorg
-requires work, but I am also not convinced it's worth the cost.
+[[!meta title="Wayland: i3 to Sway migration"]]
 
-After reading [this blurb on LWN](https://lwn.net/Articles/908561/), I decided to at least document
-the situation here. The actual quote:
-
-> It’s amazing. I have never experienced gaming on Linux that looked
-> this smooth in my life.
-
-... I'm not a gamer, but I *do* [[care about
-latency|blog/2018-05-04-terminal-emulators-2]]. The [longer version is
-worth a read as well][artemis].
-
-The point here is not to bash one side or the other, or even do a
-thorough comparison. I start with the premise that Xorg is likely
-going to go away in the future (think 20 years) and that I will
-somehow need to adapt. So this is a quick tour of my current (Sept
-2022) desktop to see what needs adjusting.
-
-I have also had some pretty bad driver crashes with Xorg with
-screensharing under Firefox, in Debian bookworm, in November 2022. The
-symptom would be that the UI would completely crash, reverting to a
-text-only console, while Firefox would *keep running*, audio and
-everything still working. People could still see the screenshare, but
-I couldn't, of course, let alone interact with it. All processes still
-running, including Xorg. There were also frustrating glitches in the
-UI, and video playback in a window was laggy, sluggish, and out of
-sync.
+I started migrating my graphical workstations to Wayland, specifically
+migrating from i3 to Sway. This is mostly to address serious graphics
+bugs in the latest [[Framwork
+laptop|hardware/laptop/framework-12th-gen/]], but also something I
+felt was inevitable.
 
 The current status is that I've been able to convert my `i3`
-configuration to `sway`. Things like screen sharing are unlikely to
-work without Pipewire, and that, in turn, will require an upgrade to
-bookworm. My biggest irritant right now is that the tray icons
-(e.g. Network Manager) are not clickable (!?).
+configuration to Sway, and adapt my `systemd` startup sequence to the
+new environment. Screen sharing only works with Pipewire, so I also
+did that migration, which basically requires an upgrade to Debian
+bookworm to get a nice enough Pipewire release. My biggest irritant
+right now is that the tray icons (e.g. Network Manager) are not
+clickable (!?).
 
 I'm testing Wayland on my laptop, but I'm not using it as a daily
-driver because of those issues just yet.
+driver because I first need to upgrade to Debian bookworm there.
+
+The rest of this page documents why I made the switch, how it
+happened, and what's left to do.
 
-TL;DR:
+TL;DR: Wayland is [mostly ready][arewewaylandyet.com]. Main blockers you might find are
+that you need to do manual configurations, [DisplayLink](https://en.wikipedia.org/wiki/DisplayLink) (multiple
+monitors on a single cable) doesn't work in Sway, HDR and color
+management are still in development. I installed the following
+packages:
 
     apt install \
         brightnessctl \
@@ -53,10 +41,71 @@ TL;DR:
         wlr-randr \
         xdg-desktop-portal-wlr
 
-And lots of tweaks in my `$HOME`.
+And did some of tweaks in my `$HOME`, mostly dealing with my esoteric
+systemd startup sequence, which you won't have to deal with if you are
+not a fan.
 
 [[!toc levels=5]]
 
+# Why switch?
+
+I originally held back from migrating to Wayland: it seemed like a
+complicated endeavor hardly worth the cost. It also didn't seem
+actually ready.
+
+But after reading [this blurb on LWN](https://lwn.net/Articles/908561/), I decided to at least
+document the situation here. The actual quote that convinced me it
+might be worth it was:
+
+> It’s amazing. I have never experienced gaming on Linux that looked
+> this smooth in my life.
+
+... I'm not a gamer, but I *do* [[care about
+latency|blog/2018-05-04-terminal-emulators-2]]. The [longer version is
+worth a read as well][artemis].
+
+The point here is not to bash one side or the other, or even do a
+thorough comparison. I start with the premise that Xorg is likely
+going away in the future and that I will need to adapt some day. In
+fact, the [last Xorg release](https://lists.x.org/archives/xorg/2021-October/060799.html) (21.1.0, October 2021) is [rumored to
+be the last](https://who-t.blogspot.com/2021/09/an-xorg-release-without-xwayland.html) ("just like the previous release...", that
+said). Indeed, it seems even core Xorg people have moved on to
+developing Wayland, or at least Xwayland, which was spun off it its
+own source tree.
+
+X, or at least Xorg, in in maintenance mode and has been for
+years. Granted, the [X Window System](https://en.wikipedia.org/wiki/X_Window_System) is getting close to forty
+years old at this point: it got us amazingly far for something that
+was designed around the time the [first](https://en.wikipedia.org/wiki/Xerox_Alto) [graphical
+interface](https://en.wikipedia.org/wiki/Macintosh_128). Since Mac and (especially?) Windows released theirs,
+they have rebuilt their graphical backends numerous times, but UNIX
+derivatives have stuck on Xorg this entire time, which is a testament
+to the design and reliability of X. (Or our incapacity at developing
+meaningful architectural change across the entire ecosystem, take your
+pick I guess.)
+
+What pushed me over the edge is that I had some pretty bad driver
+crashes with Xorg while screen sharing under Firefox, in Debian
+bookworm (around November 2022). The symptom would be that the UI
+would completely crash, reverting to a text-only console, while
+Firefox would *keep running*, audio and everything still
+working. People could still see my screen, but I couldn't, of course,
+let alone interact with it. All processes still running, including
+Xorg.
+
+(And no, sorry, I haven't reported that bug, maybe I should have, and
+it's actually possible it comes up again in Wayland, of course. But at
+first, screen sharing didn't work of course, so it's coming a much
+further way. After making screen sharing work, though, the bug didn't
+occur again, so I consider this a Xorg-specific problem until further
+notice.)
+
+There were also frustrating glitches in the UI, in general. I actually
+had to setup a compositor alongside i3 to make things bearable at
+all. Video playback in a window was laggy, sluggish, and out of sync.
+
+Wayland fixed all of this.
+
 [artemis]: https://artemis.sh/2022/09/18/wayland-from-an-x-apologist.html
 
 # Window manager: i3 → sway

sample cgls
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index b039d671..c9b34d2c 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -606,6 +606,110 @@ is typically done with a desktop file, so drop
 [sway-user-service](https://gitlab.com/anarcat/puppet/-/blob/main/site-modules/profile/files/sway/sway-user-service) somewhere in your `$PATH` (typically
 `/usr/bin/sway-user-service`).
 
+The session looks like this:
+
+    $ systemd-cgls | head -101
+    Control group /:
+    -.slice
+    ├─user.slice (#472)
+    │ → user.invocation_id: bc405c6341de4e93a545bde6d7abbeec
+    │ → trusted.invocation_id: bc405c6341de4e93a545bde6d7abbeec
+    │ └─user-1000.slice (#10072)
+    │   → user.invocation_id: 08f40f5c4bcd4fd6adfd27bec24e4827
+    │   → trusted.invocation_id: 08f40f5c4bcd4fd6adfd27bec24e4827
+    │   ├─user@1000.service … (#10156)
+    │   │ → user.delegate: 1
+    │   │ → trusted.delegate: 1
+    │   │ → user.invocation_id: 76bed72a1ffb41dca9bfda7bb174ef6b
+    │   │ → trusted.invocation_id: 76bed72a1ffb41dca9bfda7bb174ef6b
+    │   │ ├─session.slice (#10282)
+    │   │ │ ├─xdg-document-portal.service (#12248)
+    │   │ │ │ ├─9533 /usr/libexec/xdg-document-portal
+    │   │ │ │ └─9542 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,subt…
+    │   │ │ ├─xdg-desktop-portal.service (#12211)
+    │   │ │ │ └─9529 /usr/libexec/xdg-desktop-portal
+    │   │ │ ├─pipewire-pulse.service (#10778)
+    │   │ │ │ └─6002 /usr/bin/pipewire-pulse
+    │   │ │ ├─wireplumber.service (#10519)
+    │   │ │ │ └─5944 /usr/bin/wireplumber
+    │   │ │ ├─gvfs-daemon.service (#10667)
+    │   │ │ │ └─5960 /usr/libexec/gvfsd
+    │   │ │ ├─gvfs-udisks2-volume-monitor.service (#10852)
+    │   │ │ │ └─6021 /usr/libexec/gvfs-udisks2-volume-monitor
+    │   │ │ ├─at-spi-dbus-bus.service (#11481)
+    │   │ │ │ ├─6210 /usr/libexec/at-spi-bus-launcher
+    │   │ │ │ ├─6216 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2…
+    │   │ │ │ └─6450 /usr/libexec/at-spi2-registryd --use-gnome-session
+    │   │ │ ├─pipewire.service (#10403)
+    │   │ │ │ └─5940 /usr/bin/pipewire
+    │   │ │ └─dbus.service (#10593)
+    │   │ │   └─5946 /usr/bin/dbus-daemon --session --address=systemd: --nofork --n…
+    │   │ ├─background.slice (#10324)
+    │   │ │ └─tracker-miner-fs-3.service (#10741)
+    │   │ │   └─6001 /usr/libexec/tracker-miner-fs-3
+    │   │ ├─app.slice (#10240)
+    │   │ │ ├─xdg-permission-store.service (#12285)
+    │   │ │ │ └─9536 /usr/libexec/xdg-permission-store
+    │   │ │ ├─gammastep.service (#11370)
+    │   │ │ │ └─6197 gammastep
+    │   │ │ ├─dunst.service (#11958)
+    │   │ │ │ └─7460 /usr/bin/dunst
+    │   │ │ ├─wterminal.service (#13980)
+    │   │ │ │ ├─69100 foot --title pop-up
+    │   │ │ │ ├─69101 /bin/bash
+    │   │ │ │ ├─77660 sudo systemd-cgls
+    │   │ │ │ ├─77661 head -101
+    │   │ │ │ ├─77662 wl-copy
+    │   │ │ │ ├─77663 sudo systemd-cgls
+    │   │ │ │ └─77664 systemd-cgls
+    │   │ │ ├─syncthing.service (#11995)
+    │   │ │ │ ├─7529 /usr/bin/syncthing -no-browser -no-restart -logflags=0 --verbo…
+    │   │ │ │ └─7537 /usr/bin/syncthing -no-browser -no-restart -logflags=0 --verbo…
+    │   │ │ ├─dconf.service (#10704)
+    │   │ │ │ └─5967 /usr/libexec/dconf-service
+    │   │ │ ├─gnome-keyring-daemon.service (#10630)
+    │   │ │ │ └─5951 /usr/bin/gnome-keyring-daemon --foreground --components=pkcs11…
+    │   │ │ ├─gcr-ssh-agent.service (#10963)
+    │   │ │ │ └─6035 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
+    │   │ │ ├─swayidle.service (#11444)
+    │   │ │ │ └─6199 /usr/bin/swayidle -w
+    │   │ │ ├─nm-applet.service (#11407)
+    │   │ │ │ └─6198 /usr/bin/nm-applet --indicator
+    │   │ │ ├─wcolortaillog.service (#11518)
+    │   │ │ │ ├─6226 foot colortaillog
+    │   │ │ │ ├─6228 /bin/sh /home/anarcat/bin/colortaillog
+    │   │ │ │ ├─6230 sudo journalctl -f
+    │   │ │ │ ├─6233 ccze -m ansi
+    │   │ │ │ ├─6235 sudo journalctl -f
+    │   │ │ │ └─6236 journalctl -f
+    │   │ │ ├─afuse.service (#10889)
+    │   │ │ │ └─6051 /usr/bin/afuse -o mount_template=sshfs -o transform_symlinks -…
+    │   │ │ ├─gpg-agent.service (#13547)
+    │   │ │ │ ├─51662 /usr/bin/gpg-agent --supervised
+    │   │ │ │ └─51719 scdaemon --multi-server
+    │   │ │ ├─emacs.service (#10926)
+    │   │ │ │ ├─ 6034 /usr/bin/emacs --fg-daemon
+    │   │ │ │ └─33203 /usr/bin/aspell -a -m -d en --encoding=utf-8
+    │   │ │ ├─xdg-desktop-portal-gtk.service (#12322)
+    │   │ │ │ └─9546 /usr/libexec/xdg-desktop-portal-gtk
+    │   │ │ ├─xdg-desktop-portal-wlr.service (#12359)
+    │   │ │ │ └─9555 /usr/libexec/xdg-desktop-portal-wlr
+    │   │ │ └─sway.service (#11037)
+    │   │ │   ├─6037 /usr/bin/sway
+    │   │ │   ├─6181 swaybar -b bar-0
+    │   │ │   ├─6209 py3status
+    │   │ │   ├─6309 /usr/bin/i3status -c /tmp/py3status_oy4ntfnq
+    │   │ │   └─6969 Xwayland :0 -rootless -terminate -core -listen 29 -listen 30 -…
+    │   │ └─init.scope (#10198)
+    │   │   ├─5909 /lib/systemd/systemd --user
+    │   │   └─5911 (sd-pam)
+    │   └─session-7.scope (#10440)
+    │     ├─5895 gdm-session-worker [pam/gdm-password]
+    │     ├─6028 /usr/libexec/gdm-wayland-session --register-session sway-user-serv…
+    [...]
+
+I think that's pretty neat.
+
  * TODO: consider this improved script: <https://github.com/xdbob/sway-services/blob/master/bin/sway-user-service>
  * TODO: move config into Puppet so it's in sync
  * TODO: maybe submit as a PR on the debian package?

document my systemd services
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index d363cb2f..b039d671 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -526,7 +526,7 @@ See also [this list](https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway
 
 # Other issues
 
-## systemd startup failure
+## systemd integration
 
 Startup is a problem. I used to have my whole session started from
 `.xsession` like this:
@@ -559,15 +559,56 @@ logging in over (say) SSH.
 features systemd integration. It involves starting a different session
 in a completely new `.desktop` file. That work was [submitted
 upstream](https://github.com/swaywm/sway/pull/3486) but refused on the grounds that "I'd rather not give a
-preference to any particular init system." The work was therefore
-[moved to the wiki](https://github.com/swaywm/sway/wiki/Systemd-integration), which I should probably follow. See also
-[sway-services](https://github.com/xdbob/sway-services) and [uwsm](https://github.com/Vladimir-csp/uwsm) (not in Debian).
+preference to any particular init system." Another PR was
+[abandoned](https://github.com/swaywm/sway/issues/5160#issuecomment-641173221) on the grounds that "restarting [sway] does not makes
+sense: that kills everything".
+
+The work was therefore [moved to the wiki](https://github.com/swaywm/sway/wiki/Systemd-integration).
+
+So. Not a great situation. The [upstream wiki](https://github.com/swaywm/sway/wiki/) [systemd
+integration](https://github.com/swaywm/sway/wiki/Systemd-integration) suggests starting the systemd target *from within
+Sway*, which has all sorts of problems:
+
+ * you don't get Sway logs anywhere
+ * control groups are all messed up
+
+I have done a lot of work trying to figure this out, but I remember
+that didn't actually work for me: my previously configured systemd
+units didn't correctly start, and especially not with the right
+path. 
+
+So I went down that rabbit hole and managed to correctly configure
+Sway to be started from the `systemd --user` session. 
+I have partly followed the wiki but also picked ideas from damjan's
+[sway-setup](https://github.com/gdamjan/sway-setup) and xdbob's [sway-services](https://github.com/xdbob/sway-services). Another option is
+[uwsm](https://github.com/Vladimir-csp/uwsm) (not in Debian).
+
+This is the config I have in `.config/systemd/user/`:
+
+ * [[sway.service]]
+ * [[sway-session.target]]
+
+I have also configured those services, but that's somewhat optional:
+
+ * [[gammastep.service]]
+ * [[swayidle.service]]
+ * [[wcolortaillog.service]]
+ * [[wterminal.service]]
+
+You will also need at least part of my [[sway/config|config]], which
+sends the systemd notification (because, no, Sway doesn't support any
+sort of readiness notification, that would be too easy). And you might
+like to see my [[swayidle-config]] while you're there.
+
+Finally, you need to hook this up somehow to the login manager. This
+is typically done with a desktop file, so drop
+[sway-session.desktop](https://gitlab.com/anarcat/puppet/-/blob/0499fc3036570985a8e92a4e11d7bebb3d69a36c/site-modules/profile/files/sway/sway-session.desktop) in `/usr/share/wayland-sessions` and
+[sway-user-service](https://gitlab.com/anarcat/puppet/-/blob/main/site-modules/profile/files/sway/sway-user-service) somewhere in your `$PATH` (typically
+`/usr/bin/sway-user-service`).
 
  * TODO: consider this improved script: <https://github.com/xdbob/sway-services/blob/master/bin/sway-user-service>
- * TODO: document my working systemd config
+ * TODO: move config into Puppet so it's in sync
  * TODO: maybe submit as a PR on the debian package?
- * TODO: document another reason why upstream doesn't want systemd
-   support: <https://www.reddit.com/r/swaywm/comments/px0w11/swaybar_using_tray_bindcode_andor_tray_bindsym/>
 
 ## environment failure
 
diff --git a/software/desktop/wayland/config b/software/desktop/wayland/config
new file mode 100644
index 00000000..386c3c1e
--- /dev/null
+++ b/software/desktop/wayland/config
@@ -0,0 +1,423 @@
+# sway config file
+#
+# Sway has (unfortunately) no reference manual. The homepage says it
+# is "documented via manpages":
+#
+# https://swaywm.org/
+#
+# So I guess start with this and good luck?
+#
+# https://manpages.debian.org/sway
+#
+# This configuration was migrated from my i3 config in November 2022,
+# by following this:
+#
+# https://github.com/swaywm/sway/wiki/i3-Migration-Guide
+#
+# ... and many other pages.
+#
+# TODO:
+#
+# * assign certain clients to certain windows, to bootstrap session
+#   properly: https://i3wm.org/docs/userguide.html#assign_workspace
+# * resize keybindings are weird: "up" should move the *boundary* up,
+#   not shrink/grow, because that's context-specific
+
+# left "windows" key
+set $mod Mod4
+
+# Font for window titles. Will also be used by the bar unless a different font
+# is used in the bar {} block below.
+# This font is widely installed, provides lots of unicode glyphs, right-to-left
+# text rendering and scalability on retina/hidpi displays (thanks to pango).
+font pango:Fira mono 10
+# Before i3 v4.8, we used to recommend this one as the default:
+# font -misc-fixed-medium-r-normal--13-120-75-75-C-70-iso10646-1
+# The font above is very space-efficient, that is, it looks good, sharp and
+# clear in small sizes. However, its unicode glyph coverage is limited, the old
+# X core fonts rendering does not support right-to-left and this being a bitmap
+# font, it doesn’t scale on retina/hidpi displays.
+
+# Use Mouse+$mod to drag floating windows to their wanted position
+floating_modifier $mod
+
+# guess vertical vs horizontal orientation based on screen size
+default_orientation auto
+
+# going to workspace 3 twice brings me back
+workspace_auto_back_and_forth no
+
+# wait before canceling urgency to see which window warned
+force_display_urgency_hint 500 ms
+
+# do not show window title, just a thin, one-pixel border
+default_border pixel 1
+
+# start a terminal
+bindsym $mod+Return exec foot
+
+# kill focused window
+#bindsym $mod+Shift+q kill
+# xmonad backwards-compat
+bindsym $mod+Shift+c kill
+
+# start dmenu (a program launcher)
+bindsym $mod+d exec dmenu_run
+
+# There also is the (new) i3-dmenu-desktop which only displays applications
+# shipping a .desktop file. It is a wrapper around dmenu, so you need that
+# installed.
+# bindsym $mod+d exec --no-startup-id i3-dmenu-desktop
+
+# change focus
+bindsym $mod+j focus left
+bindsym $mod+k focus down
+bindsym $mod+l focus up
+bindsym $mod+semicolon focus right
+
+# alternatively, you can use the cursor keys:
+#bindsym $mod+Left focus left
+bindsym $mod+Down focus down
+bindsym $mod+Up focus up
+#bindsym $mod+Right focus right
+
+#bindsym $mod+Tab focus right
+#bindsym $mod+Shift+Tab focus left
+
+# this unfortunately doesn't work
+#bindsym $mod+Tab focus next
+#bindsym $mod+Shift+Tab focus prev
+
+# https://gitlab.com/anarcat/scripts/blob/master/i3-focus
+bindsym $mod+Tab exec sway-focus next
+bindsym $mod+Shift+Tab exec sway-focus prev
+
+# move focused window
+bindsym $mod+Shift+j move left
+bindsym $mod+Shift+k move down
+bindsym $mod+Shift+l move up
+bindsym $mod+Shift+semicolon move right
+
+# alternatively, you can use the cursor keys:
+bindsym $mod+Shift+Left move left
+bindsym $mod+Shift+Down move down
+bindsym $mod+Shift+Up move up
+bindsym $mod+Shift+Right move right
+
+# split in horizontal orientation
+bindsym $mod+h split h
+
+# split in vertical orientation
+bindsym $mod+v split v
+
+# enter fullscreen mode for the focused container
+bindsym $mod+f fullscreen
+
+# change container layout (stacked, tabbed, toggle split)
+bindsym $mod+s layout stacking
+bindsym $mod+w layout tabbed

(Diff truncated)
done: put desktop and script in puppet
Still have to document all the mishmash of scripts I ended up with
here, but at least it works now.
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 02fa1355..d363cb2f 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -563,9 +563,9 @@ preference to any particular init system." The work was therefore
 [moved to the wiki](https://github.com/swaywm/sway/wiki/Systemd-integration), which I should probably follow. See also
 [sway-services](https://github.com/xdbob/sway-services) and [uwsm](https://github.com/Vladimir-csp/uwsm) (not in Debian).
 
- * TODO: put desktop file and script in puppet
  * TODO: consider this improved script: <https://github.com/xdbob/sway-services/blob/master/bin/sway-user-service>
- * TODO: share some of the service stuff here, maybe submit as a PR on the debian package?
+ * TODO: document my working systemd config
+ * TODO: maybe submit as a PR on the debian package?
  * TODO: document another reason why upstream doesn't want systemd
    support: <https://www.reddit.com/r/swaywm/comments/px0w11/swaybar_using_tray_bindcode_andor_tray_bindsym/>
 

more tricks
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 22396f22..02fa1355 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -511,6 +511,9 @@ need to:
    ... but it seems innocuous. The tray icon displays but, as stated
    above, is not clickable. If you don't see the icon, check the
    `bar.tray_output` property in the Sway config, try: `tray_output *`.
+   Note that there is currently (November 2022) a [pull request](https://github.com/swaywm/sway/pull/6249) to
+   hook up a "Tray D-Bus Menu" which, [according to Reddit](https://www.reddit.com/r/swaywm/comments/px0w11/swaybar_using_tray_bindcode_andor_tray_bindsym/) might
+   fix this, or at least be somewhat relevant.
 
  * window switcher: currently using a hacked up `i3-focus` script,
    will probably need porting, [swayr](https://sr.ht/~tsdh/swayr/) an option, not in Debian,
@@ -563,7 +566,8 @@ preference to any particular init system." The work was therefore
  * TODO: put desktop file and script in puppet
  * TODO: consider this improved script: <https://github.com/xdbob/sway-services/blob/master/bin/sway-user-service>
  * TODO: share some of the service stuff here, maybe submit as a PR on the debian package?
- * TODO: this has a pre.target: https://github.com/xdbob/sway-services/tree/master/systemd
+ * TODO: document another reason why upstream doesn't want systemd
+   support: <https://www.reddit.com/r/swaywm/comments/px0w11/swaybar_using_tray_bindcode_andor_tray_bindsym/>
 
 ## environment failure
 

document my latest firefox startup hack
Turns out this is much simpler than i thought.
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 71f3e9bb..22396f22 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -80,12 +80,16 @@ report](https://bugzilla.mozilla.org/show_bug.cgi?id=635134) is still open and i
 depends on 76 open bugs, it was opened *twelve* (2010) years ago, and
 it's still getting daily updates (mostly linking to other tickets).
 
-Firefox depends on this silly variable to start correctly:
+## How to enable it
+
+Firefox depends on this silly variable to start correctly under
+Wayland (otherwise it starts inside Xwayland and looks fuzzy and fails
+to screen share):
 
     MOZ_ENABLE_WAYLAND=1 firefox
 
-To make the change permanent, add this to an environment startup
-script:
+To make the change permanent, many recipes recommend adding this to an
+environment startup script:
 
     if [ "$XDG_SESSION_TYPE" == "wayland" ]; then
         export MOZ_ENABLE_WAYLAND=1
@@ -106,9 +110,16 @@ solution to have a conditional `MOZ_ENABLE_WAYLAND` environment, but
 I'm not sure it would work because ordering between those two isn't
 clear: maybe the `XDG_SESSION_TYPE` wouldn't be set just yet...)
 
-For now I have made [this ridiculous script](https://gitlab.com/anarcat/scripts/-/blob/main/firefox) to workaround those
-issues but, really, it seems to me Firefox should just parse the
-`XDG_SESSION_TYPE` variable here...
+At first, I made [this ridiculous script](https://gitlab.com/anarcat/scripts/-/blob/3184996fa3e8050aed07451c16b72d69bcb2cd1b/firefox) to workaround those
+issues. Really, it seems to me Firefox should just parse the
+`XDG_SESSION_TYPE` variable here... but then I realized that Firefox
+works fine in Xorg when the `MOZ_ENABLE_WAYLAND` is set.
+
+So now I just set that variable in `environment.d` and It Just Works™:
+
+    MOZ_ENABLE_WAYLAND=1
+
+## Screen sharing
 
 Out of the box, screen sharing doesn't work until you install
 [xdg-desktop-portal-wlr](https://github.com/emersion/xdg-desktop-portal-wlr/). I had to reboot for the change to take

explain more why i am switching, because i am, basically
+ toc levels
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index a73c7e9f..71f3e9bb 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -17,6 +17,16 @@ going to go away in the future (think 20 years) and that I will
 somehow need to adapt. So this is a quick tour of my current (Sept
 2022) desktop to see what needs adjusting.
 
+I have also had some pretty bad driver crashes with Xorg with
+screensharing under Firefox, in Debian bookworm, in November 2022. The
+symptom would be that the UI would completely crash, reverting to a
+text-only console, while Firefox would *keep running*, audio and
+everything still working. People could still see the screenshare, but
+I couldn't, of course, let alone interact with it. All processes still
+running, including Xorg. There were also frustrating glitches in the
+UI, and video playback in a window was laggy, sluggish, and out of
+sync.
+
 The current status is that I've been able to convert my `i3`
 configuration to `sway`. Things like screen sharing are unlikely to
 work without Pipewire, and that, in turn, will require an upgrade to
@@ -45,7 +55,7 @@ TL;DR:
 
 And lots of tweaks in my `$HOME`.
 
-[[!toc]]
+[[!toc levels=5]]
 
 [artemis]: https://artemis.sh/2022/09/18/wayland-from-an-x-apologist.html
 

another portal trick
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index aaf76f4d..a73c7e9f 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -115,6 +115,12 @@ it streams *only* [one output](https://github.com/emersion/xdg-desktop-portal-wl
 of the time! See the [screencast compatibility](https://github.com/emersion/xdg-desktop-portal-wlr/wiki/Screencast-Compatibility) for more
 information on what is supposed to work.
 
+TODO: setting a `chooser_cmd` might allow us to pick the output to
+share, see [xdg-desktop-portal-wlr(1)](https://manpages.debian.org/xdg-desktop-portal-wlr). This could double as a
+security measure, to make sure the user accepts a screen sharing
+request. That might also, at least in theory, allow us to stream only
+a window or square.
+
 [environment.d(5)]: https://manpages.debian.org/environment.d
 [systemd.environment-generator(7)]: https://manpages.debian.org/systemd.environment-generator
 

fix indentation
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index ac64fd7b..aaf76f4d 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -533,10 +533,10 @@ preference to any particular init system." The work was therefore
 [moved to the wiki](https://github.com/swaywm/sway/wiki/Systemd-integration), which I should probably follow. See also
 [sway-services](https://github.com/xdbob/sway-services) and [uwsm](https://github.com/Vladimir-csp/uwsm) (not in Debian).
 
-TODO: put desktop file and script in puppet
-TODO: consider this improved script: <https://github.com/xdbob/sway-services/blob/master/bin/sway-user-service>
-TODO: share some of the service stuff here, maybe submit as a PR on the debian package?
-TODO: this has a pre.target: https://github.com/xdbob/sway-services/tree/master/systemd
+ * TODO: put desktop file and script in puppet
+ * TODO: consider this improved script: <https://github.com/xdbob/sway-services/blob/master/bin/sway-user-service>
+ * TODO: share some of the service stuff here, maybe submit as a PR on the debian package?
+ * TODO: this has a pre.target: https://github.com/xdbob/sway-services/tree/master/systemd
 
 ## environment failure
 

more wayland notes
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index e4214ac1..ac64fd7b 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -18,10 +18,10 @@ somehow need to adapt. So this is a quick tour of my current (Sept
 2022) desktop to see what needs adjusting.
 
 The current status is that I've been able to convert my `i3`
-configuration to `sway`. A lot of work remains to fix my systemd user
-session so that everything starts up correctly, and all other little
-details below. Things like screen sharing are unlikely to work without
-Pipewire, and that, in turn, will require an upgrade to bookworm.
+configuration to `sway`. Things like screen sharing are unlikely to
+work without Pipewire, and that, in turn, will require an upgrade to
+bookworm. My biggest irritant right now is that the tray icons
+(e.g. Network Manager) are not clickable (!?).
 
 I'm testing Wayland on my laptop, but I'm not using it as a daily
 driver because of those issues just yet.
@@ -382,6 +382,8 @@ In the end, I am just using `swayidle` with a configuration based on
     [Install]
     WantedBy=sway-session.target
 
+Interestingly, damjan also has a [service for swaylock](https://github.com/gdamjan/sway-setup/blob/main/systemd/user/swaylock.service) itself,
+although it's not clear to me what its purpose is...
 
 # Screenshot: maim → grim, pubpaste a blocker
 
@@ -453,17 +455,36 @@ need to:
             xkb_options "grp:sclk_toggle"
         }
 
+   that works refreshingly well. [swaykbdd](https://github.com/artemsen/swaykbdd) is an alternative that
+   supports per-window layouts (in Debian).
+
  * wallpaper: currently using feh, will need a replacement, TODO:
    figure out something that does, like feh, a random shuffle.
-   [swaybg](https://github.com/swaywm/swaybg) just loads a *single* image, duh
+   [swaybg](https://github.com/swaywm/swaybg) just loads a *single* image, duh. [oguri](https://github.com/vilhalmer/oguri) might be a
+   solution, but unmaintained, [used here](https://github.com/xdbob/sway-services/blob/master/systemd/oguri.service), not in
+   Debian. [wallutils](https://github.com/xyproto/wallutils) is another option, also not in Debian.
 
  * notifications: currently using dunst in some places, could
    generalize, not a blocker, [salut](https://gitlab.com/snakedye/salut/) a possible alternative (not
-   in Debian), TODO: `dunst.service` startup
+   in Debian), damjan [uses mako](https://github.com/gdamjan/sway-setup/blob/main/systemd/user/mako.service)
 
  * notification area: looks like `nm-applet` is gone, TODO: bring back
-   the notification area?
+   the notification area? maybe [check this service](https://github.com/gdamjan/sway-setup/blob/main/systemd/user/nm-applet.service)?  In theory,
+   [tray icon support was merged in 1.5](https://github.com/swaywm/sway/pull/3249), but in practice there are
+   still [several limitations](https://github.com/swaywm/sway/issues/3799), like [icons not clickable](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985205). On
+   startup, `nm-applet --indicator` triggers this error in the Sway
+   logs:
    
+        nov 11 22:34:12 angela sway[298938]: 00:49:42.325 [INFO] [swaybar/tray/host.c:24] Registering Status Notifier Item ':1.47/org/ayatana/NotificationItem/nm_applet'
+        nov 11 22:34:12 angela sway[298938]: 00:49:42.327 [ERROR] [swaybar/tray/item.c:127] :1.47/org/ayatana/NotificationItem/nm_applet IconPixmap: No such property “IconPixmap”
+        nov 11 22:34:12 angela sway[298938]: 00:49:42.327 [ERROR] [swaybar/tray/item.c:127] :1.47/org/ayatana/NotificationItem/nm_applet AttentionIconPixmap: No such property “AttentionIconPixmap”
+        nov 11 22:34:12 angela sway[298938]: 00:49:42.327 [ERROR] [swaybar/tray/item.c:127] :1.47/org/ayatana/NotificationItem/nm_applet ItemIsMenu: No such property “ItemIsMenu”
+        nov 11 22:36:10 angela sway[313419]: info: fcft.c:838: /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf: size=24.00pt/32px, dpi=96.00
+
+   ... but it seems innocuous. The tray icon displays but, as stated
+   above, is not clickable. If you don't see the icon, check the
+   `bar.tray_output` property in the Sway config, try: `tray_output *`.
+
  * window switcher: currently using a hacked up `i3-focus` script,
    will probably need porting, [swayr](https://sr.ht/~tsdh/swayr/) an option, not in Debian,
    update: put together [this bespoke hack](https://gitlab.com/anarcat/scripts/-/blob/main/sway-focus) from multiple sources
@@ -515,6 +536,7 @@ preference to any particular init system." The work was therefore
 TODO: put desktop file and script in puppet
 TODO: consider this improved script: <https://github.com/xdbob/sway-services/blob/master/bin/sway-user-service>
 TODO: share some of the service stuff here, maybe submit as a PR on the debian package?
+TODO: this has a pre.target: https://github.com/xdbob/sway-services/tree/master/systemd
 
 ## environment failure
 
@@ -558,7 +580,22 @@ See also:
  * <https://github.com/swaywm/sway/wiki/i3-Migration-Guide>
 
 TODO: see also the pubpaste section for xdotool
-TODO: `autorandr` conversion... [kanshi][]?
+TODO: `autorandr` conversion... [kanshi][]? see [this service
+file](https://github.com/xdbob/sway-services/blob/master/systemd/kanshi.service). wallutils can also do this, apparently.
+
+## arandr
+
+arandr is not directly part of X, but there's also no cleary
+established equivalent... [arewewaylandyet.com][] refers to a few:
+
+| Project          | In Debian |
+|------------------|-----------|
+| [wdisplays][]    | yes       |
+| [nwg-displays][] | no        |
+
+
+[wdisplays]: https://github.com/artizirk/wdisplays
+[nwg-displays]: https://github.com/nwg-piotr/nwg-displays
 
 # Improvements over i3
 
@@ -577,6 +614,10 @@ TODO: You can tweak the display latency in wlroots compositors with the
 [`max_render_time`](https://manpages.debian.org/bullseye/sway/sway.5.en.html) parameter, possibly getting lower latency than
 X11 in the end.
 
+## Sound/brightness changes notifications
+
+TODO: [Avizo](https://github.com/misterdanb/avizo) can display a pop-up to give feedback on volume and
+brightness changes. Not in Debian.
 
 # Debugging tricks
 

basic sway implementation, this is now production-ready
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index baf569bd..e4214ac1 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -187,8 +187,8 @@ Sept. 2022) list the following alternatives:
  * [wl-gammaray](https://github.com/jeremija/wl-gammarelay): fork of gammastep, runs as a DBUS service
  * [wlsunset](https://git.sr.ht/~kennylevinsen/wlsunset): [WNPP](http://bugs.debian.org/992729)
 
-TODO: `gammastep -l 45.51:-73.55 -v -t 5700:3600` seems to work, put
-in a config file, add service file.
+I configured `gammastep` with a simple `gammastep.service` file
+associated with the `sway-session.target`.
 
 # Terminal: xterm → foot?
 
@@ -363,8 +363,25 @@ Other than that, maybe it's time to just let go of those funky
 animations and just let swaylock do it's thing, which is display a
 static image or just a black screen, which is fine by me.
 
-TODO: swayidle, probably requires refactoring the systemd session, see
-<https://github.com/swaywm/sway/wiki/Systemd-integration#swayidle>
+In the end, I am just using `swayidle` with a configuration based on
+[the systemd integration wiki page](https://github.com/swaywm/sway/wiki/Systemd-integration#swayidle) but with additional tweaks from
+[this service](https://github.com/xdbob/sway-services/blob/master/systemd/swayidle.service.in):
+
+    [Unit]
+    Description=Idle manager for Wayland
+    Documentation=man:swayidle(1)
+    PartOf=graphical-session.target
+    Requires=sway-session.target
+    After=sway-session.target
+
+    [Service]
+    Type=simple
+    ExecStart=/usr/bin/swayidle -w
+    Restart=always
+
+    [Install]
+    WantedBy=sway-session.target
+
 
 # Screenshot: maim → grim, pubpaste a blocker
 
@@ -436,8 +453,9 @@ need to:
             xkb_options "grp:sclk_toggle"
         }
 
- * wallpaper: currently using feh, will need a replacement,
-   TODO: try [swaybg](https://github.com/swaywm/swaybg)
+ * wallpaper: currently using feh, will need a replacement, TODO:
+   figure out something that does, like feh, a random shuffle.
+   [swaybg](https://github.com/swaywm/swaybg) just loads a *single* image, duh
 
  * notifications: currently using dunst in some places, could
    generalize, not a blocker, [salut](https://gitlab.com/snakedye/salut/) a possible alternative (not
@@ -494,8 +512,9 @@ preference to any particular init system." The work was therefore
 [moved to the wiki](https://github.com/swaywm/sway/wiki/Systemd-integration), which I should probably follow. See also
 [sway-services](https://github.com/xdbob/sway-services) and [uwsm](https://github.com/Vladimir-csp/uwsm) (not in Debian).
 
-TODO: make a `wayland-session.target` bound to
-`graphical-session.target`, start it from a separate desktop file
+TODO: put desktop file and script in puppet
+TODO: consider this improved script: <https://github.com/xdbob/sway-services/blob/master/bin/sway-user-service>
+TODO: share some of the service stuff here, maybe submit as a PR on the debian package?
 
 ## environment failure
 
@@ -510,9 +529,6 @@ systemd, and it fixes a bunch of other problems. I used to have a
 with that approach is that it doesn't support conditionals, but that's
 something that's rarely needed (except for Firefox, above).
 
-TODO: the environment is not actually picked up right now, *except* in
-rofi, super weird.
-
 # X11 / Wayland equivalents
 
 For all the tools above, it's not exactly clear what options exist in

yet more todos, sort some stuff
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index f2c2f1ab..baf569bd 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -510,6 +510,9 @@ systemd, and it fixes a bunch of other problems. I used to have a
 with that approach is that it doesn't support conditionals, but that's
 something that's rarely needed (except for Firefox, above).
 
+TODO: the environment is not actually picked up right now, *except* in
+rofi, super weird.
+
 # X11 / Wayland equivalents
 
 For all the tools above, it's not exactly clear what options exist in
@@ -543,6 +546,8 @@ TODO: `autorandr` conversion... [kanshi][]?
 
 # Improvements over i3
 
+## Tiling improvements
+
 There's a lot of improvements Sway could bring over using plain
 i3. There are pretty neat auto-tilers that could replicate the
 configurations I used to have in Xmonad or Awesome, see:
@@ -550,6 +555,13 @@ configurations I used to have in Xmonad or Awesome, see:
  * [autotiling](https://github.com/nwg-piotr/autotiling)
  * [swaymonad](https://github.com/nicolasavru/swaymonad)
 
+## Display latency tweaks
+
+TODO: You can tweak the display latency in wlroots compositors with the
+[`max_render_time`](https://manpages.debian.org/bullseye/sway/sway.5.en.html) parameter, possibly getting lower latency than
+X11 in the end.
+
+
 # Debugging tricks
 
 The `xeyes` (in the `x11-apps` package) will run in Wayland, and can
@@ -561,10 +573,6 @@ Another way to see what is using Wayland in Sway is with the command:
 
     swaymsg -t get_tree
 
-You can tweak the display latency in wlroots compositors with the
-[`max_render_time`](https://manpages.debian.org/bullseye/sway/sway.5.en.html) parameter, possibly getting lower latency than
-X11 in the end.
-
 # Other documentation
 
  * [awesome-wayland][]

more sway programs and todos
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 0bf45ed8..f2c2f1ab 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -38,7 +38,9 @@ TL;DR:
         sway \
         swayidle \
         swaylock \
+        wev \
         wireplumber \
+        wlr-randr \
         xdg-desktop-portal-wlr
 
 And lots of tweaks in my `$HOME`.
@@ -378,7 +380,7 @@ One key problem here is that I have my own screenshot / pastebin
 software which will need an update for Wayland as well, see
 [pubpaste](https://gitlab.com/anarcat/pubpaste).
 
-TODO: test pubpaste, switch to grim
+TODO: add Wayland support for pubpaste (grim and wl-clipboard, basically)
 
 # Screen recorder: simplescreenrecorder → wf-recorder
 
@@ -439,7 +441,7 @@ need to:
 
  * notifications: currently using dunst in some places, could
    generalize, not a blocker, [salut](https://gitlab.com/snakedye/salut/) a possible alternative (not
-   in Debian), TODO: dunst.service startup
+   in Debian), TODO: `dunst.service` startup
 
  * notification area: looks like `nm-applet` is gone, TODO: bring back
    the notification area?
@@ -515,13 +517,16 @@ Wayland, or when they do, which one should be used. But for some basic
 tools, it seems the options are actually quite clear. If that's the
 case, they should be listed here:
 
-| X11        | Wayland       | In Debian |
-|------------|---------------|-----------|
-| autorandr  | [kanshi][]    | yes       |
-| xdotool    | [wtype][]     | yes       |
-| xev        | [wev][]       | yes       |
-| xlsclients | [lswt][]      | no        |
-| xrandr     | [wlr-randr][] | yes       |
+| X11          | Wayland               | In Debian |
+|--------------|-----------------------|-----------|
+| `autorandr`  | [kanshi][]            | yes       |
+| `xdotool`    | [wtype][]             | yes       |
+| `xev`        | [wev][]               | yes       |
+| `xlsclients` | `swaymsg -t get_tree` | yes       |
+| `xrandr`     | [wlr-randr][]         | yes       |
+
+[lswt][] is a more direct replacement for `xlsclients` but is not
+packaged in Debian.
 
 [lswt]: https://git.sr.ht/~leon_plickat/lswt
 [wev]: https://git.sr.ht/~sircmpwn/wev
@@ -533,7 +538,8 @@ See also:
  * <https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway>
  * <https://github.com/swaywm/sway/wiki/i3-Migration-Guide>
 
-TODO: `autorandr`
+TODO: see also the pubpaste section for xdotool
+TODO: `autorandr` conversion... [kanshi][]?
 
 # Improvements over i3
 
@@ -541,8 +547,8 @@ There's a lot of improvements Sway could bring over using plain
 i3. There are pretty neat auto-tilers that could replicate the
 configurations I used to have in Xmonad or Awesome, see:
 
- * https://github.com/nwg-piotr/autotiling
- * https://github.com/nicolasavru/swaymonad
+ * [autotiling](https://github.com/nwg-piotr/autotiling)
+ * [swaymonad](https://github.com/nicolasavru/swaymonad)
 
 # Debugging tricks
 
@@ -559,13 +565,15 @@ You can tweak the display latency in wlroots compositors with the
 [`max_render_time`](https://manpages.debian.org/bullseye/sway/sway.5.en.html) parameter, possibly getting lower latency than
 X11 in the end.
 
-# Other lists
+# Other documentation
 
  * [awesome-wayland][]
  * [arewewaylandyet.com][]
  * [hacktivist.me notes][]
  * [Arch Linux wiki](https://wiki.archlinux.org/title/Wayland)
  * [Gentoo apps list](https://wiki.gentoo.org/wiki/Wayland_Desktop_Landscape)
+ * [Sway: useful addons](https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway)
+ * [i3 migration guide](https://github.com/swaywm/sway/wiki/i3-Migration-Guide)
 
 [awesome-wayland]: https://github.com/natpen/awesome-wayland
 

update summary, i might just switch after all
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index e8d5ca25..0bf45ed8 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -19,10 +19,29 @@ somehow need to adapt. So this is a quick tour of my current (Sept
 
 The current status is that I've been able to convert my `i3`
 configuration to `sway`. A lot of work remains to fix my systemd user
-session so that everything starts up correctly. Firefox screen sharing
-still doesn't work and is the biggest blocker right now. I'm testing
-Wayland on my laptop, but I'm not using it as a daily driver because
-of this.
+session so that everything starts up correctly, and all other little
+details below. Things like screen sharing are unlikely to work without
+Pipewire, and that, in turn, will require an upgrade to bookworm.
+
+I'm testing Wayland on my laptop, but I'm not using it as a daily
+driver because of those issues just yet.
+
+TL;DR:
+
+    apt install \
+        brightnessctl \
+        foot \
+        gammastep \
+        gdm3 \
+        grim slurp \
+        pipewire-pulse \
+        sway \
+        swayidle \
+        swaylock \
+        wireplumber \
+        xdg-desktop-portal-wlr
+
+And lots of tweaks in my `$HOME`.
 
 [[!toc]]
 

screensharing works!!
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index cef9cd0b..e8d5ca25 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -40,7 +40,7 @@ I have invested quite a bit of effort in setting up my status bar with
 [py3status](https://py3status.readthedocs.io/). It supports Sway directly, and does not actually
 require any change.
 
-# Web browser: Firefox, screen sharing blocker
+# Web browser: Firefox
 
 Firefox has had support for Wayland for a while now, with the team
 [enabling it by default in nightlies around January 2022](https://www.phoronix.com/news/Firefox-Nightly-Wayland-Rolling). It's
@@ -79,16 +79,41 @@ For now I have made [this ridiculous script](https://gitlab.com/anarcat/scripts/
 issues but, really, it seems to me Firefox should just parse the
 `XDG_SESSION_TYPE` variable here...
 
-Besides, screen sharing doesn't work at all: it's blank in Xwayland
-mode and just doesn't do anything in Wayland mode. It shows the usual
-permission prompt with "Use operating system settings" as the only
-choice and when we accept, nothing happens. This was tested in Debian
-bookworm/testing with Firefox ESR 102 and Firefox 106.
+Out of the box, screen sharing doesn't work until you install
+[xdg-desktop-portal-wlr](https://github.com/emersion/xdg-desktop-portal-wlr/). I had to reboot for the change to take
+effect. Otherwise it shows the usual permission prompt with "Use
+operating system settings" as the only choice and when we accept,
+nothing happens.
+
+This was tested in Debian bookworm/testing with Firefox ESR 102 and
+Firefox 106.
+
+Major caveat: we can only share a full screen, we [can't currently
+share just a window](https://github.com/emersion/xdg-desktop-portal-wlr/wiki/FAQ#will-this-let-me-share-individual-windows). The major upside to that is that, by default,
+it streams *only* [one output](https://github.com/emersion/xdg-desktop-portal-wlr/wiki/FAQ#will-this-let-me-share-all-of-my-outputsdisplays-at-once) which is actually what I want most
+of the time! See the [screencast compatibility](https://github.com/emersion/xdg-desktop-portal-wlr/wiki/Screencast-Compatibility) for more
+information on what is supposed to work.
 
 [environment.d(5)]: https://manpages.debian.org/environment.d
 [systemd.environment-generator(7)]: https://manpages.debian.org/systemd.environment-generator
 
-TODO: figure out the blocker for screensharing, which bug to follow.
+## Chrome fails to share a full screen
+
+I actually still use Google Chrome (or, more accurately, Debian's
+Chromium package) for some videoconferencing. It's mainly because
+chromium is the only browser which will allow me to share only one of
+my two monitors, which is extremely useful.
+
+To start chrome with the Wayland backend, you need to use:
+
+    chromium  -enable-features=UseOzonePlatform -ozone-platform=wayland
+
+Unfortunately, chrome doesn't work as well as one would expect under
+Wayland. In Sway, it shows a huge gray border around the browser. It
+*can* however, do *some* screensharing. Sharing a window and a tab
+seems to work, but sharing a full screen doesn't: it's all
+black. Definitely not ready for prime time, but it might actually work
+to share one monitor at a time.
 
 # Email: notmuch
 
@@ -235,8 +260,11 @@ depends on xdotool for some operations. At first, I thought this was
 just going to be (thankfully?) impossible, because we actually *like*
 the idea that one app cannot send keystrokes to another. But it seems
 there *are* actually alternatives to this, like [wtype][] or
-[ydotool](https://github.com/ReimuNotMoe/ydotool), the latter which requires root access. So who knows how
-well any of that actually works...
+[ydotool](https://github.com/ReimuNotMoe/ydotool), the latter which requires root access. [wl-ime-type][]
+does that through the `input-method-unstable-v2` protocol ([sample
+emoji picker][], but is not
+packaged in Debian. So who knows how well any of that actually
+works...
 
 The other problem is that I actually heavily modified rofi. I use
 "modis" which are not actually implemented in wofi *or* tofi, so I'm
@@ -268,6 +296,8 @@ reintegrated...
 [wmenu]: https://sr.ht/~adnano/wmenu/
 [Wofi]: https://hg.sr.ht/~scoopta/wofi
 [yofi]: https://github.com/l4l/yofi
+[wl-ime-type]: https://git.sr.ht/~emersion/wl-ime-type
+[sample emoji picker]: https://git.sr.ht/~emersion/dotfiles/tree/master/item/bin/emoji-menu
 
 # Image viewers: geeqie → ?
 

more foot tricks
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index ec643cc0..cef9cd0b 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -163,8 +163,11 @@ crisper than Xterm and Emacs. URLs are not clickable but the URL
 selector (<kbd>control-shift-u</kbd>) is just plain awesome. The
 word-wrapping is excellent, it doesn't lose one bit. Copy-paste
 works. True colors work. Emojis are nicely sized and colored. Font
-resize works. I feel like switching to Wayland just for this little
-goodie, but I need to try it for longer to really be sure.
+resize works. There's even scrollback search
+(<kbd>control-shift-r</kbd>).
+
+I feel like switching to Wayland just for this little goodie, but I
+need to try it for longer to really be sure.
 
 The selection clicks are a not quite what I would expect though. In
 rxvt and others, you have the following patterns:
@@ -190,6 +193,8 @@ eventually resolve itself, as Debian bookworm has a newer
 version. Note that some corrections were also shipped in the
 [20211113](https://invisible-island.net/ncurses/NEWS.html#index-t20211113) release, but that is also shipped in Debian bookworm.
 
+The [foot wiki](https://codeberg.org/dnkl/foot/wiki) has good troubleshooting instructions as well.
+
 # Launcher: rofi → rofi? xdotool a blocker
 
 rofi does [not support Wayland](https://github.com/davatorium/rofi/issues/446). There was a [rather disgraceful

ncurses issues with foot
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index b8337335..ec643cc0 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -180,6 +180,16 @@ selected. You can select a rectangle with square, and it correctly
 extends the selection word-wise with right click if double-click was
 first used.
 
+Another problem with foot is that it's a new terminal, with its own
+[termcap](https://en.wikipedia.org/wiki/Termcap) entry. Support for foot was added to ncurses in the
+[20210731](https://invisible-island.net/ncurses/NEWS.html#index-t20210731) release, which was shipped *after* the current Debian
+stable release (Debian bullseye, which ships 6.2+20201114-2). A
+workaround to this problem is to install the `foot-terminfo` package
+on the remote host, which *is* available in Debian stable. This should
+eventually resolve itself, as Debian bookworm has a newer
+version. Note that some corrections were also shipped in the
+[20211113](https://invisible-island.net/ncurses/NEWS.html#index-t20211113) release, but that is also shipped in Debian bookworm.
+
 # Launcher: rofi → rofi? xdotool a blocker
 
 rofi does [not support Wayland](https://github.com/davatorium/rofi/issues/446). There was a [rather disgraceful

more alternatives to systemd services
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 2449aaa7..b8337335 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -425,7 +425,8 @@ features systemd integration. It involves starting a different session
 in a completely new `.desktop` file. That work was [submitted
 upstream](https://github.com/swaywm/sway/pull/3486) but refused on the grounds that "I'd rather not give a
 preference to any particular init system." The work was therefore
-[moved to the wiki](https://github.com/swaywm/sway/wiki/Systemd-integration).
+[moved to the wiki](https://github.com/swaywm/sway/wiki/Systemd-integration), which I should probably follow. See also
+[sway-services](https://github.com/xdbob/sway-services) and [uwsm](https://github.com/Vladimir-csp/uwsm) (not in Debian).
 
 TODO: make a `wayland-session.target` bound to
 `graphical-session.target`, start it from a separate desktop file

document all remaining todos and bugs
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index fed279f9..2449aaa7 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -17,6 +17,13 @@ going to go away in the future (think 20 years) and that I will
 somehow need to adapt. So this is a quick tour of my current (Sept
 2022) desktop to see what needs adjusting.
 
+The current status is that I've been able to convert my `i3`
+configuration to `sway`. A lot of work remains to fix my systemd user
+session so that everything starts up correctly. Firefox screen sharing
+still doesn't work and is the biggest blocker right now. I'm testing
+Wayland on my laptop, but I'm not using it as a daily driver because
+of this.
+
 [[!toc]]
 
 [artemis]: https://artemis.sh/2022/09/18/wayland-from-an-x-apologist.html
@@ -27,13 +34,13 @@ This seems like kind of a no-brainer. [Sway](http://swaywm.org/) is around, it's
 feature-complete, and it's in Debian. Presumably, one can probably
 just reuse their i3 config directly as well?
 
-# Status bar: py3status?
+# Status bar: py3status
 
 I have invested quite a bit of effort in setting up my status bar with
-[py3status](https://py3status.readthedocs.io/). It *seems* like it has support for Sway directly, and
-might not actually require any change.
+[py3status](https://py3status.readthedocs.io/). It supports Sway directly, and does not actually
+require any change.
 
-# Web browser: Firefox
+# Web browser: Firefox, screen sharing blocker
 
 Firefox has had support for Wayland for a while now, with the team
 [enabling it by default in nightlies around January 2022](https://www.phoronix.com/news/Firefox-Nightly-Wayland-Rolling). It's
@@ -42,10 +49,9 @@ report](https://bugzilla.mozilla.org/show_bug.cgi?id=635134) is still open and i
 depends on 76 open bugs, it was opened *twelve* (2010) years ago, and
 it's still getting daily updates (mostly linking to other tickets).
 
-So who knows... I guess we can assume this just works already? To
-test, try:
+Firefox depends on this silly variable to start correctly:
 
-    MOZ_ENABLE_WAYLAND=1
+    MOZ_ENABLE_WAYLAND=1 firefox
 
 To make the change permanent, add this to an environment startup
 script:
@@ -54,11 +60,35 @@ script:
         export MOZ_ENABLE_WAYLAND=1
     fi
 
-Update: it looks like `XDG_SESSION_TYPE` is not actually set when
-starting Sway from `gdm3` which I find really confusing. So the above
-trick doesn't actually work. And besides, the environment doesn't load
-in the first place (see below), so I had to manually start Firefox for
-now. Screen sharing doesn't work at all: blank.
+At least that's the theory. In practice, Sway doesn't actually run any
+startup shell script, so that can't possibly work. Furthermore,
+`XDG_SESSION_TYPE` is not actually set when starting Sway from `gdm3`
+which I find really confusing, and I'm not the [only](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021545) [one](https://github.com/swaywm/sway/pull/4876). So
+the above trick doesn't actually work, even if the environment
+(`XDG_SESSION_TYPE`) *is* set correctly, because we don't have
+conditionals in [environment.d(5)][].
+
+(Note that [systemd.environment-generator(7)][] *do* support running
+arbitrary commands to generate environment, but for some some do not
+support user-specific configuration files... Even then it *may* be a
+solution to have a conditional `MOZ_ENABLE_WAYLAND` environment, but
+I'm not sure it would work because ordering between those two isn't
+clear: maybe the `XDG_SESSION_TYPE` wouldn't be set just yet...)
+
+For now I have made [this ridiculous script](https://gitlab.com/anarcat/scripts/-/blob/main/firefox) to workaround those
+issues but, really, it seems to me Firefox should just parse the
+`XDG_SESSION_TYPE` variable here...
+
+Besides, screen sharing doesn't work at all: it's blank in Xwayland
+mode and just doesn't do anything in Wayland mode. It shows the usual
+permission prompt with "Use operating system settings" as the only
+choice and when we accept, nothing happens. This was tested in Debian
+bookworm/testing with Firefox ESR 102 and Firefox 106.
+
+[environment.d(5)]: https://manpages.debian.org/environment.d
+[systemd.environment-generator(7)]: https://manpages.debian.org/systemd.environment-generator
+
+TODO: figure out the blocker for screensharing, which bug to follow.
 
 # Email: notmuch
 
@@ -74,7 +104,7 @@ Emacs is being actively ported to Wayland. According to [this LWN
 article](https://lwn.net/Articles/843896/), the first (partial, to Cairo) port was done in 2014 and a
 working port (to GTK3) was completed in 2021, but wasn't merged until
 [late 2021](https://batsov.com/articles/2021/12/19/building-emacs-from-source-with-pgtk/), that is: after [Emacs 28 was released](https://www.gnu.org/savannah-checkouts/gnu/emacs/emacs.html#Releases) (April
-2022). So we'll probably need to way for Emacs 29 to have native
+2022). So we'll probably need to wait for Emacs 29 to have native
 support there.
 
 Still, like many X11 applications, Emacs will probably work fine under
@@ -85,6 +115,8 @@ Scaling is a bit of an issue: fonts look fuzzy.
 I have heard anecdotal evidence of hard lockups with Emacs running
 under Xwayland as well.
 
+TODO: look again at Wayland in Emacs 29.
+
 # Backups: borg
 
 Mostly irrelevant, as I do not use a GUI.
@@ -109,6 +141,9 @@ Sept. 2022) list the following alternatives:
  * [wl-gammaray](https://github.com/jeremija/wl-gammarelay): fork of gammastep, runs as a DBUS service
  * [wlsunset](https://git.sr.ht/~kennylevinsen/wlsunset): [WNPP](http://bugs.debian.org/992729)
 
+TODO: `gammastep -l 45.51:-73.55 -v -t 5700:3600` seems to work, put
+in a config file, add service file.
+
 # Terminal: xterm → foot?
 
 One of the biggest question mark in this transition is what to do
@@ -131,7 +166,21 @@ works. True colors work. Emojis are nicely sized and colored. Font
 resize works. I feel like switching to Wayland just for this little
 goodie, but I need to try it for longer to really be sure.
 
-# Launcher: rofi → ??? xdotool also a blocker
+The selection clicks are a not quite what I would expect though. In
+rxvt and others, you have the following patterns:
+
+ * single click: reset selection, or drag to select
+ * double: select word
+ * triple: select quotes or line
+ * quadruple: select line
+
+I particularly find the "select quotes" bit useful. It seems like foot
+just supports double and triple clicks, with word and line
+selected. You can select a rectangle with square, and it correctly
+extends the selection word-wise with right click if double-click was
+first used.
+
+# Launcher: rofi → rofi? xdotool a blocker
 
 rofi does [not support Wayland](https://github.com/davatorium/rofi/issues/446). There was a [rather disgraceful
 battle in the pull request](https://github.com/davatorium/rofi/pull/1139) that led to the creation of a fork
@@ -222,6 +271,8 @@ Alternatives:
  * [swayimg](https://github.com/artemsen/swayimg): overlay, in Debian
  * [vimiv](https://karlch.github.io/vimiv/): vim-like keybindings, not in Debian
 
+TODO: pick an alternative to geeqie, see if nomacs can be fixed?
+
 # Screensaver: xsecurelock → swaylock
 
 I'm currently using xss-lock and xsecurelock as a screensaver, with
@@ -246,6 +297,9 @@ Other than that, maybe it's time to just let go of those funky
 animations and just let swaylock do it's thing, which is display a
 static image or just a black screen, which is fine by me.
 
+TODO: swayidle, probably requires refactoring the systemd session, see
+<https://github.com/swaywm/sway/wiki/Systemd-integration#swayidle>
+
 # Screenshot: maim → grim, pubpaste a blocker
 
 I'm a heavy user of maim (and the package maintainer in Debian). It
@@ -260,6 +314,8 @@ One key problem here is that I have my own screenshot / pastebin
 software which will need an update for Wayland as well, see
 [pubpaste](https://gitlab.com/anarcat/pubpaste).
 
+TODO: test pubpaste, switch to grim
+
 # Screen recorder: simplescreenrecorder → wf-recorder
 
 I am currently using peek or simplescreenrecorder for screenshots. The
@@ -300,6 +356,7 @@ need to:
 
  * `.Xresources` - say goodbye and convert to application-specific
    configurations
+
  * keyboard layout switcher: built-in to Sway since 2017 ([PR
    1505](https://github.com/swaywm/sway/pull/1505), 1.5rc2+), will require a configuration change, see [this
    answer](https://unix.stackexchange.com/a/425433/30227) as well, looks something like this command:
@@ -314,13 +371,19 @@ need to:
         }
 
  * wallpaper: currently using feh, will need a replacement,
-   [swaybg](https://github.com/swaywm/swaybg) might just be enough
+   TODO: try [swaybg](https://github.com/swaywm/swaybg)
+
  * notifications: currently using dunst in some places, could
    generalize, not a blocker, [salut](https://gitlab.com/snakedye/salut/) a possible alternative (not
-   in Debian)
+   in Debian), TODO: dunst.service startup
+
+ * notification area: looks like `nm-applet` is gone, TODO: bring back
+   the notification area?
+   
  * window switcher: currently using a hacked up `i3-focus` script,
    will probably need porting, [swayr](https://sr.ht/~tsdh/swayr/) an option, not in Debian,
    update: put together [this bespoke hack](https://gitlab.com/anarcat/scripts/-/blob/main/sway-focus) from multiple sources
+
  * PDF viewer: could just switch to zatura/mupdf permanently, see also
    [[calibre]]
 
@@ -328,6 +391,8 @@ See also [this list](https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway

(Diff truncated)
status update: foot works, rofi is a big blocker
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index 1485201b..fed279f9 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -33,7 +33,7 @@ I have invested quite a bit of effort in setting up my status bar with
 [py3status](https://py3status.readthedocs.io/). It *seems* like it has support for Sway directly, and
 might not actually require any change.
 
-# Web browser: Firefox?
+# Web browser: Firefox
 
 Firefox has had support for Wayland for a while now, with the team
 [enabling it by default in nightlies around January 2022](https://www.phoronix.com/news/Firefox-Nightly-Wayland-Rolling). It's
@@ -68,7 +68,7 @@ See Emacs, below.
 
 See Email, above, or Emacs in Editor, below.
 
-# Editor: Emacs a blocker
+# Editor: Emacs okay-ish
 
 Emacs is being actively ported to Wayland. According to [this LWN
 article](https://lwn.net/Articles/843896/), the first (partial, to Cairo) port was done in 2014 and a
@@ -109,7 +109,7 @@ Sept. 2022) list the following alternatives:
  * [wl-gammaray](https://github.com/jeremija/wl-gammarelay): fork of gammastep, runs as a DBUS service
  * [wlsunset](https://git.sr.ht/~kennylevinsen/wlsunset): [WNPP](http://bugs.debian.org/992729)
 
-# Terminal: xterm → ???
+# Terminal: xterm → foot?
 
 One of the biggest question mark in this transition is what to do
 about Xterm. After writing two articles about terminal emulators as a
@@ -121,11 +121,17 @@ This is such a big topic that I actually have an [[entire blog post
 specifically about this|blog/2022-09-19-wayland-terminal-emulators]].
 
 For now, using xterm under Xwayland works well enough, although the
-font scaling makes things look a bit too fuzzy. I have also tried
-foot: it ... works? Would need to try it for longer to really
-tell. Fonts are certainly much crisper than Xterm and Emacs.
+font scaling makes things look a bit too fuzzy. 
 
-# Launcher: rofi → wofi? xdotool a blocker
+I have also tried foot: it ... just works? Fonts are certainly much
+crisper than Xterm and Emacs. URLs are not clickable but the URL
+selector (<kbd>control-shift-u</kbd>) is just plain awesome. The
+word-wrapping is excellent, it doesn't lose one bit. Copy-paste
+works. True colors work. Emojis are nicely sized and colored. Font
+resize works. I feel like switching to Wayland just for this little
+goodie, but I need to try it for longer to really be sure.
+
+# Launcher: rofi → ??? xdotool also a blocker
 
 rofi does [not support Wayland](https://github.com/davatorium/rofi/issues/446). There was a [rather disgraceful
 battle in the pull request](https://github.com/davatorium/rofi/pull/1139) that led to the creation of a fork
@@ -168,6 +174,12 @@ there *are* actually alternatives to this, like [wtype][] or
 [ydotool](https://github.com/ReimuNotMoe/ydotool), the latter which requires root access. So who knows how
 well any of that actually works...
 
+The other problem is that I actually heavily modified rofi. I use
+"modis" which are not actually implemented in wofi *or* tofi, so I'm
+left with reinventing those wheels from scratch or using the rofi +
+wayland fork... It's really too bad that fork isn't being
+reintegrated...
+
 [wtype]: https://github.com/atx/wtype
 [alfred]: https://github.com/albertlauncher/albert
 [bemenu]: https://github.com/Cloudef/bemenu
@@ -210,7 +222,7 @@ Alternatives:
  * [swayimg](https://github.com/artemsen/swayimg): overlay, in Debian
  * [vimiv](https://karlch.github.io/vimiv/): vim-like keybindings, not in Debian
 
-# Screensaver: xsecurelock → swaylock?
+# Screensaver: xsecurelock → swaylock
 
 I'm currently using xss-lock and xsecurelock as a screensaver, with
 xscreensaver "hacks" as a backend for xsecurelock.
@@ -266,7 +278,7 @@ program make my system less secure? To be investigated.
 Many other options are available, see the [awesome Wayland
 screencasting list](https://github.com/natpen/awesome-wayland#screencasting).
 
-# RSI: workrave → ???
+# RSI: workrave → nothing?
 
 Workrave has [no support for Wayland](https://github.com/rcaelers/workrave/issues/94). [activity watch](https://github.com/ActivityWatch/activitywatch) is a
 time tracker alternative, but is not a RSI watcher. KDE has

tried switching to Wayland today to resolve a bug in Firefox
Turns out firefox crashes my entire graphical session when I do a
screenshare. It doesn't segfault, or kill X, or anything of the sort,
no: it just kills the display, and I fall back to the terminal. The
audio still works, weirdly, and even the screenshare *does* still
work. I just can't control it of course.
Eventually that hangs and I need to reboot. I was hoping Wayland (and
Sway, in particular) could help resolve this, but the screensharing
doesn't work there either. I probably need a better combination of
Pipewire and a more recent Firefox to make this work. Who knows.
In the meantime, I got to experiment with a lot more shit, and I'm
almost functional in Sway right now. Still tons of stuff missing.
diff --git a/software/desktop/wayland.md b/software/desktop/wayland.md
index def390aa..1485201b 100644
--- a/software/desktop/wayland.md
+++ b/software/desktop/wayland.md
@@ -54,6 +54,12 @@ script:
         export MOZ_ENABLE_WAYLAND=1
     fi
 
+Update: it looks like `XDG_SESSION_TYPE` is not actually set when
+starting Sway from `gdm3` which I find really confusing. So the above
+trick doesn't actually work. And besides, the environment doesn't load
+in the first place (see below), so I had to manually start Firefox for
+now. Screen sharing doesn't work at all: blank.
+
 # Email: notmuch
 
 See Emacs, below.
@@ -72,10 +78,12 @@ working port (to GTK3) was completed in 2021, but wasn't merged until
 support there.
 
 Still, like many X11 applications, Emacs will probably work fine under
-Xwayland anyways. I suspect I will have problems with the clipboard
-and X selection, unfortunately. Scaling is also apparently an issue in
-that configuration as well. I have heard anecdotal evidence of hard
-lockups with Emacs running under Xwayland as well.
+Xwayland anyways. The clipboard works, at least, and as expected.
+
+Scaling is a bit of an issue: fonts look fuzzy.
+
+I have heard anecdotal evidence of hard lockups with Emacs running
+under Xwayland as well.
 
 # Backups: borg
 
@@ -100,7 +108,7 @@ Sept. 2022) list the following alternatives:
  * [clight](https://github.com/FedeDP/Clight): uses the webcam to probe for light
  * [wl-gammaray](https://github.com/jeremija/wl-gammarelay): fork of gammastep, runs as a DBUS service
  * [wlsunset](https://git.sr.ht/~kennylevinsen/wlsunset): [WNPP](http://bugs.debian.org/992729)
- 
+
 # Terminal: xterm → ???
 
 One of the biggest question mark in this transition is what to do
@@ -112,6 +120,11 @@ happy with *any* of them.
 This is such a big topic that I actually have an [[entire blog post
 specifically about this|blog/2022-09-19-wayland-terminal-emulators]].
 
+For now, using xterm under Xwayland works well enough, although the
+font scaling makes things look a bit too fuzzy. I have also tried
+foot: it ... works? Would need to try it for longer to really
+tell. Fonts are certainly much crisper than Xterm and Emacs.
+
 # Launcher: rofi → wofi? xdotool a blocker
 
 rofi does [not support Wayland](https://github.com/davatorium/rofi/issues/446). There was a [rather disgraceful
@@ -217,6 +230,10 @@ attempts to solve this problem, although not directly using the real
 xscreensaver hacks. [swaylock-effects](https://github.com/mortie/swaylock-effects/) is another attempt at this,
 but it only adds more effects, it doesn't delegate the image display.
 
+Other than that, maybe it's time to just let go of those funky
+animations and just let swaylock do it's thing, which is display a
+static image or just a black screen, which is fine by me.
+
 # Screenshot: maim → grim, pubpaste a blocker
 
 I'm a heavy user of maim (and the package maintainer in Debian). It
@@ -260,6 +277,10 @@ issues under Wayland ([escape doesn't work](https://github.com/slgobinath/SafeEy
 work](https://github.com/slgobinath/SafeEyes/issues/391), it just doesn't work really). [timekpr-next](https://mjasnik.gitlab.io/timekpr-next/) *could* be
 an alternative as well, and has support for Wayland.
 
+I am also considering just abandoning workrave, even if I stick with
+xorg, because it apparently introduces significant latency in the
+input pipeline.
+
 # Other apps
 
 This is a constantly changing list, but for now it seems like I'll
@@ -272,6 +293,13 @@ need to:
    answer](https://unix.stackexchange.com/a/425433/30227) as well, looks something like this command:
    
         swaymsg input 0:0:X11_keyboard xkb_layout de
+    
+   update, using this config:
+   
+        input * {
+            xkb_layout "ca,us"
+            xkb_options "grp:sclk_toggle"
+        }
 
  * wallpaper: currently using feh, will need a replacement,
    [swaybg](https://github.com/swaywm/swaybg) might just be enough
@@ -279,10 +307,48 @@ need to:
    generalize, not a blocker, [salut](https://gitlab.com/snakedye/salut/) a possible alternative (not
    in Debian)
  * window switcher: currently using a hacked up `i3-focus` script,
-   will probably need porting, [swayr](https://sr.ht/~tsdh/swayr/) an option, not in Debian
+   will probably need porting, [swayr](https://sr.ht/~tsdh/swayr/) an option, not in Debian,
+   update: put together [this bespoke hack](https://gitlab.com/anarcat/scripts/-/blob/main/sway-focus) from multiple sources
  * PDF viewer: could just switch to zatura/mupdf permanently, see also
    [[calibre]]
 
+See also [this list](https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway) and [this other list](https://github.com/swaywm/sway/wiki/i3-Migration-Guide).
+
+# Other issues
+
+Startup is a problem. I used to have my whole session started from
+`.xsession` like this:
+
+    #!/bin/sh
+
+    . ~/.shenv
+
+    # import the stuff from .shenv, above
+    systemctl --user import-environment
+
+    # ... in favor of this
+    exec systemctl --user start --wait xsession.target
+
+    # vincent bernat instead does this:
+    #
+    #     systemctl --user daemon-reload
+    #     exec systemctl --user start --wait i3.service
+    #
+    # ... which i find a bit bizarre: why don't we start the
+    # xsession.target instead? why reload the daemon?
+
+But obviously, the `xsession.target` is not started by the Sway
+session. It seems to just start a `default.target`, which is really
+not what we want because we want to associate the services directly
+with the `graphical-session.target`, so that they don't start when
+logging in over (say) SSH.
+
+The `import-envirnment` bit is also lacking: it's not clear to me how
+exactly Wayland gets started or where to inject environment. See this
+discussion:
+
+https://github.com/swaywm/sway/wiki/Setting-Environmental-Variables
+
 # X11 / Wayland equivalents
 
 For all the tools above, it's not exactly clear what options exist in
@@ -303,6 +369,20 @@ case, they should be listed here:
 [wlr-randr]: https://sr.ht/~emersion/wlr-randr/
 [kanshi]: https://sr.ht/~emersion/kanshi/
 
+See also:
+
+ * <https://github.com/swaywm/sway/wiki/Useful-add-ons-for-sway>
+ * <https://github.com/swaywm/sway/wiki/i3-Migration-Guide>
+
+# Improvements over i3
+
+There's a lot of improvements Sway could bring over using plain
+i3. There are pretty neat auto-tilers that could replicate the
+configurations I used to have in Xmonad or Awesome, see:
+
+ * https://github.com/nwg-piotr/autotiling
+ * https://github.com/nicolasavru/swaymonad
+
 # Debugging tricks
 
 The `xeyes` (in the `x11-apps` package) will run in Wayland, and can
@@ -310,6 +390,10 @@ actually be used to easily see if a given window is *also* in
 Wayland. If the "eyes" follow the cursor, the app is actually running
 in xwayland, so not natively in Wayland.
 
+Another way to see what is using Wayland in Sway is with the command:
+
+    swaymsg -t get_tree
+
 You can tweak the display latency in wlroots compositors with the
 [`max_render_time`](https://manpages.debian.org/bullseye/sway/sway.5.en.html) parameter, possibly getting lower latency than
 X11 in the end.

try to verify my mastodon account
diff --git a/index.mdwn b/index.mdwn
index 06b25e49..2827d68a 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -54,4 +54,5 @@ Tous les wikis on un [[bac à sable|SandBox]], donc lui aussi.
 
 <small>*Ceci est mon wiki. Il y en a beaucoup comme ça mais celui là c'est le [mien](https://en.wikipedia.org/wiki/Full_Metal_Jacket).*</small>
 
+<a rel="me" href="https://kolektiva.social/@Anarcat"></a>
 </div>

clarify what the fix is for now for dupe uids
diff --git a/blog/2021-11-21-mbsync-vs-offlineimap.md b/blog/2021-11-21-mbsync-vs-offlineimap.md
index c6c910d8..53512456 100644
--- a/blog/2021-11-21-mbsync-vs-offlineimap.md
+++ b/blog/2021-11-21-mbsync-vs-offlineimap.md
@@ -336,7 +336,8 @@ this (although there are [hacks](https://github.com/afewmail/afew/issues/313) th
 worked hard to make my tagging scripts idempotent, and it's something
 [afew doesn't currently have](https://github.com/afewmail/afew/issues/308). Still, it would be better to have
 that code in Python than bash, so maybe I should consider my options
-here.
+here. For now, I'm still using those [pre-new](https://gitlab.com/anarcat/scripts/-/blob/main/notmuch-purge) and [post-new](https://gitlab.com/anarcat/scripts/-/blob/main/notmuch-tag)
+scripts which workaround that problem.
 
 ## Stability issues
 

bell in prompt
diff --git a/blog/2022-11-08-modern-bell-urgency.md b/blog/2022-11-08-modern-bell-urgency.md
index d37e07a3..639714e2 100644
--- a/blog/2022-11-08-modern-bell-urgency.md
+++ b/blog/2022-11-08-modern-bell-urgency.md
@@ -163,6 +163,11 @@ command terminates, in all my shells. I have this in my
 
     PROMPT_COMMAND='printf "\a"'
 
+Or you can just put it directly in the shell prompt, with something
+like:
+
+    PS1='\[\a\]'"$PS1"
+
 (I have the equivalent in my own `.bashrc`, although that thing is
 much more complex, featuring multi-command pipeline exit status,
 colors, terminal title setting, and more, which should probably
diff --git a/blog/2022-11-08-modern-bell-urgency/comment_2_28bd9e4677bc5fb70086d428421e2eb3._comment b/blog/2022-11-08-modern-bell-urgency/comment_2_28bd9e4677bc5fb70086d428421e2eb3._comment
new file mode 100644
index 00000000..c282bce9
--- /dev/null
+++ b/blog/2022-11-08-modern-bell-urgency/comment_2_28bd9e4677bc5fb70086d428421e2eb3._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="anarcat"
+ subject="""shell escapes"""
+ date="2022-11-10T13:41:02Z"
+ content="""
+> You can directly embed the bell in `PS1`. However, you should tell your shell that it is an escape sequence (and thus not adding to prompt length): `\[\a\]`
+
+Ah! That's one bit I was missing... without that, readline gets pretty confused. Thanks! I'll update the post...
+"""]]

approve comment
diff --git a/blog/2022-11-08-modern-bell-urgency/comment_1_2e0667fb278916d4cb2e5f8fff27eb08._comment b/blog/2022-11-08-modern-bell-urgency/comment_1_2e0667fb278916d4cb2e5f8fff27eb08._comment
new file mode 100644
index 00000000..056e436b
--- /dev/null
+++ b/blog/2022-11-08-modern-bell-urgency/comment_1_2e0667fb278916d4cb2e5f8fff27eb08._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ ip="80.130.144.157"
+ claimedauthor="Helmut Grohne"
+ subject="Remarks"
+ date="2022-11-10T07:30:17Z"
+ content="""
+I'm actually using this technique for years (at least five). You don't even need a `PROMPT_COMMAND`. You can directly embed the bell in `PS1`. However, you should tell your shell that it is an escape sequence (and thus not adding to prompt length): `\[\a\]`
+
+I also confirm that this works well both in `xterm` + `awesome` on Xorg and `foot` + `sway` on wayland.
+"""]]
diff --git a/blog/2022-11-08-modern-bell-urgency/comment_1_b008b61eb06c8f479e54ad9cd628062e._comment b/blog/2022-11-08-modern-bell-urgency/comment_1_b008b61eb06c8f479e54ad9cd628062e._comment
new file mode 100644
index 00000000..345c0828
--- /dev/null
+++ b/blog/2022-11-08-modern-bell-urgency/comment_1_b008b61eb06c8f479e54ad9cd628062e._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ ip="104.162.82.124"
+ claimedauthor="Joseph"
+ subject="avoiding the beep..."
+ date="2022-11-10T02:25:54Z"
+ content="""
+Not loading the pc speaker module is the only reliable way I have found of turning off the beeps...
+
+echo \"blacklist pcspkr\" > /etc/modprobe.d/pcspkr-blacklist.conf
+
+"""]]

submarine map
diff --git a/wishlist.mdwn b/wishlist.mdwn
index 7595ca2c..c3ea15ae 100644
--- a/wishlist.mdwn
+++ b/wishlist.mdwn
@@ -10,6 +10,7 @@ Voici des choses que vous pouvez m'acheter si vous êtes le Père Nowel (yeah ri
    * [network protocols](http://i.imgur.com/MZHN3.gif)
    * [Territory of the US](http://i.imgur.com/5fz82.jpg)
    * [US military bases](http://i.imgur.com/Y4ZWY.jpg)
+   * [submarine cable map](https://blog.telegeography.com/topic/map), for example the [2022 one](https://submarine-cable-map-2022.telegeography.com/)
    * [internet maps](http://chrisharrison.net/projects/InternetMap/index.html)
    * une carte du monde [Dymaxion](http://en.wikipedia.org/wiki/Dymaxion_map), [Werner](http://en.wikipedia.org/wiki/Werner_map_projection) ou [Gall-Peters](http://en.wikipedia.org/wiki/Gall-Peters_projection)
  * <del>un laptop [novena](https://www.crowdsupply.com/kosagi/novena-open-laptop)</del>

the matrix flaw i hinted at was an actual flaw, as it turned out
diff --git a/blog/2022-06-17-matrix-notes.md b/blog/2022-06-17-matrix-notes.md
index 0428d194..30ffc4a5 100644
--- a/blog/2022-06-17-matrix-notes.md
+++ b/blog/2022-06-17-matrix-notes.md
@@ -420,6 +420,12 @@ to previous events). That signature, however, is made from the
 homeserver PKI keys, *not* the client's E2E keys, which makes E2E feel
 like it has been "bolted on" later.
 
+Update: note that this flaw has actually been called a "[serious
+vulnerability](https://arstechnica.com/information-technology/2022/09/matrix-patches-vulnerabilities-that-completely-subvert-e2ee-guarantees/)" by Ars Technica, based on a [paper from
+researchers](https://nebuchadnezzar-megolm.github.io/) that confirmed the flaw I hinted at above. The
+[response from Matrix.org](https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients) has been rather underwhelming, with many
+issues still unaddressed.
+
 # Availability
 
 While Matrix has a strong advantage over Signal in that it's
@@ -494,8 +500,8 @@ user from server B joins, the room will be replicated on server B as
 well. If server A fails, server B will keep relaying traffic to
 connected users and servers.
 
-A room is therefore not fundamentally addressed with the above alias,
-instead ,it has a internal Matrix ID, which basically a random
+A room is therefore not fundamentally addressed with the above alias.
+Instead, it has a internal Matrix ID, which basically a random
 string. It has a server name attached to it, but that was made just to
 avoid collisions. That can get a little confusing. For example, the
 `#fractal:gnome.org` room is an alias on the `gnome.org` server, but

disable visual bell in tmux
diff --git a/blog/2022-11-08-modern-bell-urgency.md b/blog/2022-11-08-modern-bell-urgency.md
index c13efe30..d37e07a3 100644
--- a/blog/2022-11-08-modern-bell-urgency.md
+++ b/blog/2022-11-08-modern-bell-urgency.md
@@ -131,8 +131,8 @@ Untested, but that is apparently how you do it:
     set -g bell-action any
     # notice bell in windows
     set -g monitor-bell on
-    # propagate bell *and* notify in tmux
-    set -g visual-bell both
+    # only propagate bell, don't warn user, as it hangs tmux for a second
+    set -g visual-bell off
     # send bell *and* notify when activity (if monitor-activity)
     set -g visual-activity both
 

Archival link:

The above link creates a machine-readable RSS feed that can be used to easily archive new changes to the site. It is used by internal scripts to do sanity checks on new entries in the wiki.

Created . Edited .