Daniel Barlow boosted

I have an observation about #wayland that may or may not have merit, which is this: changing the running compositor is hard. If you make a mistake and cause the thing to fall over you lose your session. You could run a second compositor displaying to an embedded window, or something, but that's a faff (doubly so if you have a DE that doesn't allow >1 login at once) when you want to debug something with all the windows you regularly use.

The thought which is floating around in my head is: how about a multiprocess compositor? The clients connect to a compositor which renders them in some place or other according to its scene graph, then you have one or more scene graph controllers which receive messages from input devices and send updates to the scene graph. If a controller crashes, the scene graph is intact and the clients are still connected to it - you just have to start another controller and carry on.

Daniel Barlow boosted

Daniel Barlow boosted

Why did this not occur to me previously? For any package which can be configured using a file in $HOME/.config, you can alternatively put that file in any directory in $XDG_CONFIG_DIRS

Which means you can write a derivation for it that drops the file in $out/etc/xdg

https://github.com/telent/config-nixpkgs/blob/master/pkgs/alacritty-yml/default.nix

telent/config-nixpkgs

My .config/nixpkgs directory. Contribute to telent/config-nixpkgs...

GitHub

It's quite obviously different for extension developers, where reloading an extension frequently without logging out from the running session is essential. The easiest workaround right now is using the Xorg session for extension development, which isn't great. However we should be able to cover that use case in a clean and less intrusive way by leveraging mutter's nested mode

https://bugzilla.gnome.org/show_bug.cgi?id=782187

Guess gnome-shell is never going to be repurposable as the emacs of Wayland compositors

Spent entirely too much time today trying to cleanly (declaratively, #Nix-ily) have #firefox set up with my preferred prefs and extensions, before eventually giving up and writing a small Python program to hack it.

I don't actually speak Python, I suspect this is obvious to anyone reading it that does.

https://gist.github.com/telent/05acc76ba53634ccc4b873a400326dde

(Usage notes: it sets the toolkit.policies.perUserDir pref to make firefox look for policies.json in /run/user/$UID somewhere instead of in its own lib directory - because that's readonly on Nix. Then it writes the policy json in that place. One should note that /run is ephemeral, so probably need to run this on every login)

configure-firefox.py

GitHub Gist: instantly share code, notes, and snippets.

Gist

TFW when you set out to benchmark something you've previously observed is inexplicably slow, and ... it's no slower than the other thing you're comparing it against

#nixwrt wireless performance on this gl-mt300a (MediaTek MT7620A SoC) is about ~ 14Mb/s according to iperf3, which is probably slower than I should expect but is on par with the 2.4GHz network on the gl-ar750 downstairs running the vendor's OpenWRT

$ file /nix/store/dnqj5jwld8wb0hyk5j7qjfw20810rxp8-busybox-1.31.1-mips-unknown-linux-musl/bin/busybox /nix/store/dnqj5jwld8wb0hyk5j7qjfw20810rxp8-busybox-1.31.1-mips-unknown-linux-musl/bin/busybox: ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), dynamically linked, interpreter /nix/store/pnws1x7yvmr5f710sbixwr7lhhnski8j-musl-1.1.24-mips-unknown-linux-musl/lib/ld-musl-mips.so.1, stripped hypothesis: ELF MSB MIPS is not the best choice of executable for a little-endian arch

  • The LZMA decompression code in u-boot doesn't understand the LZMA compression performed by xz, so to get #nixwrt to generate images that work I have to build the "legacy" lzma (from 2008). Upgrading nixpkgs caused its buiild to fail with "RPATH ... contains a forbidden reference to /build"

  • so I worked around that by configureFlags = [ "--enable-static" "--disable-shared"]

  • now it is building gcc again. Guess I must have changed something else fundamental ...

https://sourceforge.net/p/squashfs/mailman/message/26599379/

Daniel Barlow boosted

Happy to report have drilled holes in one wall, one ceiling and one floorboard, fed some cat5e cables through them and successfully crimped four terminators (20 years ago I knew how to make ethernet cables ...) I now have wired ethernet in my study and the difference between wired networking and powerline ethernet is the difference between 10Mb/s and 70Mb/s according to fast.com

A happy side effect for any local radio amateurs/CB users is that my mains wiring is not longer a giant radio aerial https://www.ban-plt.org.uk/

I wanted to relocate my router/wireless AP from the dining room into the living room, because (1) that's where most of the clients are most of the time; (2) makes it easy to run an ethernet cable to the TV area for the Kodi box; (3) eventually I will drop another cable from the floor above so I can have ethernet in the third bedroom (aka study) too. It could have gone simpler, especially the part where my drill bit was too short, the part where the longer drill bit I bought turned out to be very nearly too short too, and the part where it turns out I have no portable devices that have an ethernet socket, making it rather more complicated than it need be to test the cable before plugging the router into it.

Somewhere around the place I have the ethernet adapter for this thinkpad. Can I find it? Hell no.

Daniel Barlow boosted

Daniel Barlow boosted

Daniel Barlow boosted