I did not expect when I sat down this evening to write a quick script to download my withings healthmate data, that I would instead spend two hours debugging dhcp6/networkmanager config

If you can find a way to make networkmanager release a dhcp6 lease (by which I mean, not request the same wrong address again next time) you're hardier than I am

(I'm only running it because gnome objects so strongly to running without it. And I'm only running gnome because it seems to be the least worst desktop with wayland and hidpi support. Hapily gnome doesn't seem to have noticed that I have now added my primary network interface to the unmanaged list)

what is nconf (in a linux kernel config context) and why is it apparently spinning on cpu every time I save and exit?

ok, I sort of know the answer to the first part, but wth is it doing here?

``` PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 26192 dan 20 0 245780 31048 2480 R 99.7 0.2 2:57.56 nconf

```

Daniel Barlow boosted

just released version 0.4.0 of #fennel today!

https://github.com/bakpakin/Fennel/blob/master/changelog.md#040--2020-05-12

If there's a theme to this release, it's being more friendly. The compile errors now pinpoint where the problem happened and provide suggestions for how to fix them: https://p.hagelb.org/friendly.txt

We also have a brand-new setup guide for new users that covers installation, embedding, and configuring editors. Thanks to everyone who contributed and gave feedback: https://fennel-lang.org/setup

Compilation errors now don't give stack traces unless you specifically ask for them, allowing you to focus your attention on the problem instead of getting
distracted by internal details.

Installing Fennel is simpler now; rather than a launcher script, the compiler file, and an optional pretty-printer, there is a single `fennel` executable that contains it all.

Finally `import-macros` allows you to load macros similarly to `require-macros`, but it provides a lot more flexibility in how those macros are imported and what they are named.

Daniel Barlow boosted

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