OK, so OpenRC finally made it’s way into Gentoo portage. However, you should be aware that what IS in portage has some cruft /etc/init.d/functions.sh that presently doesn’t work on shells other than bash and it has a broken modules init script.Basically, the git repo hosted by Gentoo which I use now has a Gentoo branch which is what the ebuilds in portage pull from. I hate finding out about this myself without being told.
Well, since the initial OpenRC release, quite a few people where vocal on IRC bitching about it’s use of reallocing a NULL terminated char** list with claims that it’s slow and inefficient. So, I decided to take the test and rework OpenRC around the TAILQ macros as found in queue(3) for dealing with lists of strings- which it does a fair bit. After spending more time than I anticipated on this, here are the results on my slowest box measured by bash’s time feature:
When I first released dhcpcd-3, it had support for FreeBSD. This was done using a BPF device which has the benefit of getting the kernel to filter packets before they hit the program. This meant the dhcpcd only saw DHCP and ARP packets on BSD, whereas on Linux is saw all the packets coming in. Normally, this isn’t an issue as the interface isn’t configured at this point so traffic is minimal.
For some reason is vt100 or console and vt220 for the others. This causes the home/end/pgup/pgdown keys not to work correctly.Setting a term of wsvt25 in /etc/ttys fixes this! Thankfully I have no idea why that isn’t the default as it drove me potty :(
So, after finally going into a NetBSD irc channel with the express purpose of removing all compiler warnings from dhcpcd and making it add routes correctly on that platform, I got convinced into giving NetBSD a spin.
So I wanged it on my amd64 and as promised, the default cd worked fine with my trusty RT2500 pci wireless card, and the installed default kernel did too. This was an improvement from NetBSD 3.