#nixwrt is an evolutionary dead end, Liminix will be the anointed successor https://gti.telent.net/dan/liminix#what-about-nixwrt

The link describes what I’d like to do differently, although what I’ve actually done to date is mostliy noodling with the module system and other kinds of deckchair arrangement, and doesn’t build on any hardware device yet. As an only-runs-on-qemu project, some bits I’m happy with so far, some bits I think will change as the needs become apparent, and some bits I’ve not turned my attention to yet. Some bits are in more than one of those categories :-)

#nix, #nixpkgs but not

I still have running nixwrt systems at home, so in that sense it’s not dead yet - just … deadward-bound

#nixwrt on the internet:-)

Not terribly fast yet, maybe I should remove the -d -d -d from the socat instance that's forwarding all the external traffic

I won't say it's done, because it's not done. But, I can see the end from here

#nixwrt running on real hardware getting real internet traffic from a real ISP and routing to a local network

#diff-b2672dbec125801aecf42552931f00442ad5aa8d71ef085fd16e39c509573874L3" rel="nofollow">https://github.com/telent/nixwrt/commit/e0217999f6fde51698f66ef48dd83d67a4544e16#diff-b2672dbec125801aecf42552931f00442ad5aa8d71ef085fd16e39c509573874L3

#nixwrt on qemu is sending dhcp and all the gubbins to a second qemu process that I booted using a System-Rescue iso image.

This is probably an achievement. I say "probably" because I can't actually see the output from the system-rescue vm because it doesn't work properly with -serial stdio. But the packets are flowing ...

Nov 21 17:56:45 dnsmasq-dhcp[120]: 13935373 client MAC address: 52:54:00:12:34:56

Nov 21 17:56:45 dnsmasq-dhcp[120]: 13935373 client provides name: sysrescue

Nov 21 17:56:45 dnsmasq-dhcp[120]: 13935373 DHCPSOLICIT(eth1) 00:04:dc:c5:43:08:80:09:95:31:b5:c5:75:68:d8:5f:2e:2e

Nov 21 17:56:45 dnsmasq-dhcp[120]: 13935373 DHCPREPLY(eth1) 2001:8b0:de3a:40dc::f0dc

00:04:dc:c5:43:08:80:09:95:31:b5:c5:75:68:d8:5f:2e:2e sysrescue

Did a giant #nixwrt WIP commit, because I have now changed so many things at once I have given up on the prospect of it making any sense in my head.

But it's on a branch. When I get to the end of this journey (l2tp connection to my ISP and all the IPv6 prefix faff) I will ... probably print the diff and use four colours of magic marker to decide which bits to commit in what order to create some meaningful narrative

https://github.com/telent/nixwrt/compare/services-wip don't look

it is possible that NixWRT is doing a lot more compilation than it needs to (even given that there is no MIPS binary cache) because of I-didn't-understand-how-overlays-work when I wrote the overlay for it.

For example, where I wrote coreutils = super.coreutils.overrideAttrs (o: { doCheck = false } ) that changes the build system coreutils as well as the mips coreutils, so everything x86-64 that depends on coreutils is getting built from source instead of pulled from cache.

Leastways, that's how I now think it works. ICBW this time too

#nixpkgs #nixwrt

#nixwrt is running again with currentish nixpkgs-unstable, yay

Picking up the context of whatever I was doing when I dropped it, that might take longer

Yay, it's rebuilding gcc again

(Long past time I picked up #nixwrt dev again, especially as it has open pull requests)