POSIX mandates implementations must support upto a short but may exceed it. When NetBSD terminfo was implemented, no terminfo description used over a short, but because ncurses has supported ints for some time, some now do.
Infact, such a terminfo description was imported where colour pairs for screen-256color went up to 65536 which exposed a bug in the existing implementation where it was set to zero. Because the number might mean something more than a range, we need to be able to store it accurately.
So I’ve used Grav since 2017 to power my project and blog pages. It’s a flat-file Content Management System. It’s really easy to use and takes away a lot of the pain of setup. By easy to use I mean you don’t ever have to use the command line after the initial setup and the admin pages and general look and feel are really nice and clean.
Internally, Grav uses markdown files to store the user pages using frontmatter to store meta-data such as tags, publication date, etc.
DHCP clients by default send a fair chunk of data which can identify you to the local DHCP server. In return they provide you with a stable IP address and configuration parameters.
At a bare minimum, the hardware address of the interface is sent- this is required to work.
So, how to solve this dilema of wanting total anonymity? The answer is to randomise the hardware address. This will happen when the carrier is down OR dhcpcd starts with the interface down.
Whilst developing Privilege Separation in dhcpcd, I had to come up with an IPC design for it. Of course, that involves creating structures.
So far, my structures in dhcpcd are long lived- or rather the scope is design to live outside of where it was created. As such they are created on the heap and are at the mercy of malloc. Generally I use calloc so that the whole area is inited to zero as uninitialised memory is bad.
So, dhcpcd was added to DragonFlyBSD almost a year ago. Recently I’ve become a DragonFlyBSD committer with the express purpose of easing dhcpcd into the role of the default DHCP client.
All of the really needed kernel improvements are now in and dhcpcd doesn’t log any more compile warnings, but there is more work to be done such as RFC 5227 support, restarting DaD on link state up and denying the use of an address until validated.