In response to both this quote:
The user apparently believes LLMs are inherently unethical in their existence, so, by extension, any use of them is also inherently unethical, and they (the user) will therefore not use any products of LLMs in any way whatsoever.
and recent projects collecting lists of “tainted” “slopware”:
I think most absolute positions are likely incorrect, but at the same time contain merits. For example, I think the notion of abstaining entirely from any software that has been touched by an LLM (Vim? The Linux kernel?) is untenable in the long run, and I desperately hope it won’t lead to too much fragmentation of ideas. (Competing software that does it better is of course welcome.)
As another example, take explicitly condoning LLM use without a statement engaging with others’ concerns (be it quality, displacement of labor, ethics, or anything else). I can also sympathize with the absolute position that this condones and encourages other evils associated with the makers of today’s commercial LLMs. So my modulation is to take those concerns as indicative that perhaps we ought to form a community statement about what, precisely, LLM use means to Racket.
A tool and aid for continuing to do things we value? Something else?
See for example « Engineering rigor in the age of LLMs » and « The peril of laziness lost » which I have linked before. I may dislike some of Brian’s enthusiasm for them, but I also can see where he’s coming from and respect how he encourages rigorous use.
In response to this quote:
I think it’s inevitable though. Every leap in technology from books to film/video to the internet often displaces/shakes industries up. It’s either adapt or be the old man who shouts at the clouds saying “back in my day…”. Whether its generated by LLMs or not, what matters above all else is if its valuable and improves the project
I think the difficulty is pinning down meanings of « valuable » and « improves ».
Is it valuable to add new features if they also create legal risk ? Is it an improvement to automate away paper cut bugs that deprive new contributors of pathways to get started, learn the code base, and mature into maintainers?
These things are decidedly grey areas to me.
I think it’s hard to deny that there are valuable uses. I think it is equally hard to deny there are wasteful, or evil, or <other negatively connoted> uses. And I think the commercial side (even Anthropic in some ways) leans into one side more than the other, to our detriment. I think this makes it more important to qualify what our community holds dear and how LLMs fit (and don’t fit) into that equation.
]]>I recently found that, at least on Linux, the quit handler
application-quit-handler only closes the most recent window :/ not quite what
I was expecting.
But apparently I’m holding it wrong:
[we’re not] intended to call the
application-quit-handlerfrom code. Instead, I think it is a hook for reacting to requests from the desktop environment that the application please quit, just as the other handlers documented in that section respond to other events from the environment. In particular:The default handler queues a call to the
can-exit?method of the most recently active frame in the initial eventspace (and then calls the frame’son-exitmethod if the result is true). The result is#tif the eventspace is left with no open frames afteron-exitreturns,#fotherwise.
(Documentation on Windowing Functions)
Which of course makes quite a bit more sense, and should probably be stated in documentation.
I had wanted to use it as the action for my “File > Quit” menu, which now just
uses exit (I have no special cleanup to do for the moment).
I know macOS automatically provides a Quit option on .apps, which I suppose is an example of a “request[] from the desktop environment.” Do other DEs do something similar? My Gentoo box is currently running i3 without a DE, so I don’t know what typical Linux/Gtk behavior is, for example. Although a good many programs don’t have a close/quit button, which seems to imply they assume the DE will provide one. (I have keys in i3 to close them in that case.)
The framework module uses
file-menu:quit-callback
which “by default goes through the exit-related hooks in the framework.”
On non-Mac platforms, applications are supposed to add a “File > Quit” item themselves: see
file-menu:create-quit?from framework. But DEs do have other ways to ask an application to quit. Theapplication-quit-handlerdocs don’t mention other Unix, but, on KDE, right-clicking on DrRacket’s icon in my task bar and choosing Quit definitely goes through some graceful mechanism prompting me to save or cancel. Likewise if I’m logging out or rebooting. IIRC there’s an XDG spec for how to ask an application to quit.
And others say
For the File > Exit menu option in Molasses (which should probably be File > Quit), I do
(send frame on-exit). The defaulton-exithandler will in turn callon-close, which I overrode and put my custom Exit/Quit code.
This seems quite sensible also.
]]>I think both times I’ve ended up fixing this by rebooting, but I recently
learned that I can use xrandr to control the software brightness like
xrandr --output DisplayPort-3 --brightness 1
You’ll have to adjust for your output device, of course. The brightness value
appears to be a scale factor, so fractions dim the output and values greater
than 1 lead to the wash out effect.
I’m not sure what toggled the xrandr setting, but at least next time I’ll
have an idea of how to fix it.
I hadn’t thought about consensus algorithms since my MS year in 2020/2021, and I’d certainly never thought deeply about them. Studying the paper and Ousterhout’s video presentations convinced me that implementing Raft ought to be possible, in that same way that hubris is necessary to take on certain challenges. I was demonstrably humbled more than once1, but Raft’s goal (as I understand it) is to be practically implementable correctly.
The details matter immensely for correctness. Each statement is load-bearing.
As I wrote in the public README, there’s little formal validation that my implementation is faithful to any spec or upholds the relevant properties. I have a few unit tests, but I haven’t taken the dive on fuzzing or property testing this code. It deserves it. (I probably won’t try any proof tools, though if memory serves creusot exists to fill that gap.2)
I especially enjoyed explicitly modelling an abstract Clock, which I did for one
of our warmup exercises during the course—it made some reasoning deliciously
simple. Its implementation is not perfect (a sleep loop doesn’t really get you
precise ticking frequency), but a real example could tie into hardware clocks.
This is my most extensive foray into Rust to-date, though I’d dabbled a bit before. I like to say I can read Rust fairly well, having done that for years now and especially due to the writings of Ralf Jung and others. I understand a bit of the ideas Rust builds on, so I didn’t find many ownership challenges while writing this project—I intentionally structured the driver loop and main algorithm so that who owned what data was clear, except for some fiddly bits about sending application results around which end up just cloning.
I still stumble over some parts of Rust’s module system, but that got easier with time.
Rust’s tools are great, of course.
I shied away from async Rust in this project; it seemed like too much to bite off at the time. I’m more comfortable with message-passing threads from some Go (years ago) and Racket (more recent), so I usually think in that model.
In a similar way, I didn’t go dependency hunting here (I don’t browse crates.io for fun). I have serde for serialization, which ended up being more code than I thought I would have to write (integrating with serde-lexpr to use S-expression formats), and rand for randomness. There are likely other things that would be nice to glue in, and for other projects dependencies are a necessity. Here I was mostly satisfied with the standard library3.
I suspect my use of dependencies would look different if Rust’s documentation were integrated in the same way that Racket’s is, but I realize that’s less practical for a bigger ecosystem.
I’m quite pleased I was able to implement such a fascinating system in a few days of hard work: the essence was written between August 26th and 29th, with less than 20 commits afterwards4:
λ g dategraph
2025-08-26 13 ███████████████████
2025-08-27 28 ████████████████████████████████████████
2025-08-28 45 █████████████████████████████████████████████████████████████████
2025-08-29 42 █████████████████████████████████████████████████████████████
2025-09-20 1 █
2026-01-03 1 █
2026-01-04 2 ███
2026-01-05 1 █
2026-01-06 3 ████
2026-01-10 1 █
2026-01-19 3 ████
2026-02-03 4 ██████
λ DATEGRAPH=additions g dategraph
2025-08-26 652 ████████████████████████████████████████████████████████████████
2025-08-27 530 ████████████████████████████████████████████████████
2025-08-28 436 ███████████████████████████████████████████
2025-08-29 409 ████████████████████████████████████████
2025-09-20 11 █
2026-01-03 3
2026-01-04 8 █
2026-01-05 52 █████
2026-01-06 12 █
2026-01-19 45 ████
2026-02-03 204 ████████████████████
I’m also pleased I was able to return months later and reconstruct my thinking without too much hassle. A few details were peculiar, but I’ve already forgotten which ones!
And I can’t resist5:
λ g ls-files | code-percent
RowNumber File PercentTotal CumulativePercentTotal
1 src/lib.rs 30.525 30.525
2 src/test_protocol.rs 26.2913 56.8163
3 src/main.rs 11.3463 68.1626
4 README.md 9.99153 78.1541
5 src/net.rs 5.7155 83.8696
6 src/net/bytes.rs 5.63082 89.5005
7 src/test_append_entries.rs 4.65707 94.1575
8 start-cluster 1.31245 95.47
9 src/test_save_restore.rs 1.10076 96.5707
10 src/bin/client.rs 1.98984 98.5606
11 watch-cluster 0.127011 98.6876
12 start-client 0.127011 98.8146
13 src/net/config.rs 0.550381 99.365
14 .gitignore 0.211685 99.5767
15 Cargo.toml 0.42337 100
Try git log --grep fix. ↩
I have an old incomplete proof of some supposed inverses I’d like to finish, too… alas. ↩
Though not with the un-hashability of mpsc::Senders. ↩
I have a MediaTek Wireless device in my Framework desktop (outputs trimmed):
# lsusb
Bus 003 Device 003: ID 0e8d:0717 MediaTek Inc. Wireless_Device
# lshw
…
*-network
description: Ethernet interface
product: MT7925 (RZ717) Wi-Fi 7 160MHz
vendor: MEDIATEK Corp.
physical id: 0
bus info: pci@0000:c0:00.0
logical name: wlan0
version: 00
serial: ac:f2:3c:34:dd:8b
width: 64 bits
clock: 33MHz
capabilities: pciexpress msi pm bus_master cap_list ethernet physical
configuration: broadcast=yes driver=mt7925e driverversion=6.12.63-gentoo-dist firmware=____000000-20260106153120 ip=192.168.2.248 latency=0 link=yes multicast=yes
resources: irq:158 memory:b0600000-b07fffff memory:b0800000-b0807fff
…
*-usb:1
description: Bluetooth wireless interface
product: Wireless_Device
vendor: MediaTek Inc.
physical id: 3
bus info: usb@3:3
version: 1.00
serial: 000000000
capabilities: usb-2.10 bluetooth
configuration: driver=btusb maxpower=100mA speed=480Mbit/s
(The Bluetooth wireless interface is on a different pci slot from the Ethernet
interface according to lshw, but I think it’s physically part of the same
stuff?)
# hwinfo
63: PCI c000.0: 0280 Network controller
[Created at pci.386]
Unique ID: y9sn.W5ZKz6Jz0dA
Parent ID: aYFK.ZyxDeoKNER1
SysFS ID: /devices/pci0000:00/0000:00:02.3/0000:c0:00.0
SysFS BusID: 0000:c0:00.0
Hardware Class: network
Model: "MEDIATEK Network controller"
Vendor: pci 0x14c3 "MEDIATEK Corp."
Device: pci 0x0717
SubVendor: pci 0x14c3 "MEDIATEK Corp."
SubDevice: pci 0x0717
Driver: "mt7925e"
Driver Modules: "mt7925e"
Device File: wlan0
Memory Range: 0xb0600000-0xb07fffff (rw,non-prefetchable)
Memory Range: 0xb0800000-0xb0807fff (rw,non-prefetchable)
IRQ: 158 (9607 events)
HW Address: ac:f2:3c:34:dd:8b
Permanent HW Address: ac:f2:3c:34:dd:8b
Link detected: yes
Module Alias: "pci:v000014C3d00000717sv000014C3sd00000717bc02sc80i00"
Driver Info #0:
Driver Status: mt7925e is active
Driver Activation Cmd: "modprobe mt7925e"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #51 (PCI bridge)
88: USB 00.0: 0000 Unclassified device
[Created at usb.122]
Unique ID: CiZ2.dgyAFLvpDoA
Parent ID: uIhY.5sqDI7PdmUC
SysFS ID: /devices/pci0000:00/0000:00:08.3/0000:c5:00.0/usb3/3-3/3-3:1.0
SysFS BusID: 3-3:1.0
Hardware Class: unknown
Model: "MediaTek Wireless_Device"
Hotplug: USB
Vendor: usb 0x0e8d "MediaTek Inc."
Device: usb 0x0717 "Wireless_Device"
Revision: "1.00"
Serial ID: "000000000"
Driver: "btusb"
Driver Modules: "btusb"
Speed: 480 Mbps
Module Alias: "usb:v0E8Dp0717d0100dcEFdsc02dp01icE0isc01ip01in00"
Driver Info #0:
Driver Status: btusb is active
Driver Activation Cmd: "modprobe btusb"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #94 (Hub)
Anyway, after a reboot today, I saw the following issues
Feb 11 10:45:16 merguez kernel: Bluetooth: hci0: Execution of wmt command timed out
Feb 11 10:45:16 merguez kernel: Bluetooth: hci0: Failed to send wmt func ctrl (-110)
Feb 11 10:45:16 merguez kernel: Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
Things got even weirder as I started poking the hardware with various tools like
inxi, lsusb -v, and hw-probe, although that might also have been due to
removing the kernel modules and re-adding them. In particular, reloading btusb
did practically nothing; reloading mt7925e and btusb seemed to crash
Bluetooth altogether (although WiFi came back with the mt7925e driver, so it
was just the 2nd load of btusb that failed).
I was able to confirm via last that I had booted my current kernel at least
once prior to today, so I was pretty sure that wasn’t the issue (but I have
several old kernels laying around just in case):
λ ll /boot/vmlinuz-6.12.*
-rw-r--r-- 1 root root 20439552 13 oct. 21:25 /boot/vmlinuz-6.12.47-gentoo-dist
-rw-r--r-- 1 root root 20488704 13 oct. 15:35 /boot/vmlinuz-6.12.47-gentoo-dist.old
-rw-r--r-- 1 root root 20451840 7 nov. 09:20 /boot/vmlinuz-6.12.54-gentoo-dist
-rw-r--r-- 1 root root 20460032 1 déc. 16:49 /boot/vmlinuz-6.12.58-gentoo-dist
-rw-r--r-- 1 root root 20619776 29 janv. 17:09 /boot/vmlinuz-6.12.63-gentoo-dist
-rw-r--r-- 1 root root 20619776 13 janv. 08:42 /boot/vmlinuz-6.12.63-gentoo-dist.old
Turns out, the Mint folks were right: I powered down completely, left the system unplugged for a while, and then booted on with no issues.
Now the kernel logs look much nicer:
Feb 11 14:03:30 merguez kernel: Bluetooth: hci0: Device setup in 1738015 usecs
Feb 11 14:03:30 merguez kernel: Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
Feb 11 14:03:31 merguez kernel: Bluetooth: hci0: AOSP extensions version v1.00
Feb 11 14:03:31 merguez kernel: Bluetooth: hci0: AOSP quality report is supported
Feb 11 14:03:31 merguez kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Feb 11 14:03:31 merguez kernel: Bluetooth: BNEP filters: protocol multicast
Feb 11 14:03:31 merguez kernel: Bluetooth: BNEP socket layer initialized
Feb 11 14:03:31 merguez kernel: Bluetooth: MGMT ver 1.23
Feb 11 14:03:46 merguez kernel: Bluetooth: RFCOMM TTY layer initialized
Feb 11 14:03:46 merguez kernel: Bluetooth: RFCOMM socket layer initialized
Feb 11 14:03:46 merguez kernel: Bluetooth: RFCOMM ver 1.11
Feb 11 14:03:55 merguez kernel: magicmouse 0005:004C:0265.0005: unknown main item tag 0x0
Feb 11 14:03:55 merguez kernel: input: Apple Inc. Magic Trackpad 2 as /devices/virtual/misc/uhid/0005:004C:0265.0005/input/input15
Feb 11 14:03:55 merguez kernel: magicmouse 0005:004C:0265.0005: input,hidraw4: BLUETOOTH HID v3.11 Mouse [Slate] on ac:f2:3c:34:dd:8c
Of note, the drivers/bluetooth/btusb.c doesn’t list 0e8d:0717 in the
MediaTek devices, although there is what looks to my extremely untrained eyes
like some kind of generic fallback device:
/* MediaTek Bluetooth devices */
{ USB_VENDOR_AND_INTERFACE_INFO(0x0e8d, 0xe0, 0x01, 0x01),
.driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
(The docs for USB_VENDOR_AND_INTERFACE don’t mean much to me:)
/**
* USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb vendor with a class of usb interfaces
* @vend: the 16 bit USB Vendor ID
* @cl: bInterfaceClass value
* @sc: bInterfaceSubClass value
* @pr: bInterfaceProtocol value
*
* This macro is used to create a struct usb_device_id that matches a
* specific vendor with a specific class of interfaces.
*
* This is especially useful when explicitly matching devices that have
* vendor specific bDeviceClass values, but standards-compliant interfaces.
*/
#define USB_VENDOR_AND_INTERFACE_INFO(vend, cl, sc, pr) \
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
| USB_DEVICE_ID_MATCH_VENDOR, \
.idVendor = (vend), \
.bInterfaceClass = (cl), \
.bInterfaceSubClass = (sc), \
.bInterfaceProtocol = (pr)
For the network controller, we have PCI_VENDOR_ID_MEDIATEK=0x14c3 via
include/linux/pci_ids.h and then
static const struct pci_device_id mt7925_pci_device_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x7925),
.driver_data = (kernel_ulong_t)MT7925_FIRMWARE_WM },
{ PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x0717),
.driver_data = (kernel_ulong_t)MT7925_FIRMWARE_WM },
{ },
};
in the drivers/net/wireless/mediatek/mt76/mt7925 tree.
Places I looked for help via Ecosia searches of the kernel logs and model IDs:
Seems like there are lots of MediaTek driver issues, but none were exactly like mine except that Mint forum.
]]>I’m willing to be practical, but I find the « tools » conversation needs to wait until we’ve addressed at least some of the political weaponization. Ironically, this is one of the good things about the tools conversation! An LLM cannot do my job, and we should stop allowing them to be weaponized as if they could.
[What is political weaponization?]
See, e.g., Cory Doctorow’s « an LLM can’t do your job, but a salesman can convince your boss it can » for examples in employment (esp. in tech; companies would love for us to be as low-status as your average retail worker); see Grok being used to spew Musk’s many -isms or generally any attempt to dismantle the notion of truth (epistemological crisis); see US v China (Deepseek); see “AGI: Probably Not 2027” for a rebuttal of the fantasy that swept up folks in our government; see Iris Meredith’s blog for some specifics on people and projects involved (I believe I got the phrase from them—site: search is probably useful to find relevant articles).
[When pushed on how long the conversation should wait]
I can see how [“we shouldn’t be talking about how this fits into our lives as developers as a tool until the weaponization stops”] is an interpretation of my statement. I suppose I mean: I find the tool conversation fascinating, but ultimately less urgent than systemic abuse.
Right now my preferred direction of energy is toward addressing such abuse. (Of course, much like we sometimes get markers from Amazon to make our protest posters, I can use a devtool to support addressing such issues.)
In all fairness, I think a lot of spaces I’m in (including this one) are having the tool conversation in good faith. But it sure didn’t feel that way at the start, and I still can’t wrap my head around one conversation often not acknowledging the other. But there’s so much going on in a giant intersection that it also seems entirely rational to focus in on small parts at a time, and it sure seems even harder to have an all-encompassing conversation! So I’m glad to try to focus and chat however it works out.
I also find that my stubborn streak encourages me to make strong claims and then fall back to something closer to moderation in practice, provided we agree that « moderation » requires acknowledging certain indelible lines, even if we disagree how to implement those lines.
Ambiguity is probably good for us like that.
« Engineering Rigor in the Age of LLMs » has certainly given me a newfound excitement about the potential, despite all of my concerns about the « LLMentalist effect » or about the replication of harmful social norms.
I think in particular it revealed a possibility of using the tool with discernment (« this use emphatically doesn’t matter »). I hold that such discernment is difficult and is helped by engagement with all the liberal arts, including sociology and feminist theory, etc.
[What are good directions for addressing such abuse?]
Simply (hah!): envision a better world and then work for it! A few caveats: of course that’s easier said than done. Ideally, we’d be directing our talents to serve folks already doing this hard work.
Broadly, I’m looking away from computing to find these opportunities. My energies are mostly directed at things like the following. The list is too long but feels deeply connected for me.
Guiding principles:
Timeboxed:
git-reset(1)equery(1) manualgit-replay(1) manualmhash documentation buildcopy-range-diff to teach others about range-diffhledger, which I’m using to track money and budgets this yearGenerally:
Areas I want to learn more about this year:
Political ways I can get involved:
Last Changed: 2026 Apr 19
]]>I’m working on an essay (“Why I consider myself a modern Luddite”), and I’ve been thinking about situated software, the balance of power, LLMs as political tool, and trusting fellow humans quite a bit. I find the manifesto a compelling tool for establishing core values for software design. More to come…
]]>The licensing situation is unclear, so I’ve marked it “unknown” for now. In
addition, the ebuild is “live” (so only rebuilds with emerge @live-rebuild);
ZSA doesn’t publish versioned archives, as far as I can tell, so we can only
grab the latest. In spite of being version 9999, the ebuild is not actually live
in the sense of @live-rebuild. Strange.
When the archive has actually been updated, I’ll have to use ebuild $(equery w
zsa-keymapp) manifest or similar to update the Manifest. (For some reason,
pkgdev didn’t work on this one? And a couple of live ebuilds I checked don’t
have manifest information, but they also use the Git eclass for fetching.)